Introducing smart contracts in any language | Midi hacker


Koinos is the first blockchain framework built on a microservices architecture. Within this architecture is the first proto-blockchain architectured to rely almost entirely on scalable and scalable WASM smart contracts to describe system behaviors. Google’s protocol buffers (Protobuf) have always been a potential solution that we evaluate due to its high performance and fantastic language support. Koinos will now use Protobuf for serialization and take advantage of its fantastic linguistic support to make Koinos even more accessible than before.

Profile picture of Andrew Levine Hacker Noon

Andrew Levine

CEO of Koinos Group, creators of the Koinos blockchain

At Koinos Group, we want to help everyone take advantage of blockchain technology which is still far too inaccessible. This is why we build Koinos with a focus on maximization accessibility. For end users, this means allowing them to use decentralized applications without having to spend (free) money. For developers, this means allowing them to use programming languages ​​they already know instead of forcing them to learn something new.

Of course, delivering a blockchain with these capabilities requires innovative solutions, some of which we have built ourselves, but where possible, we rely on cutting-edge technologies developed by other amazing and maintained open source teams. by their independent communities. In fact, Koinos’ unparalleled scalability makes it ideally suited for integrating existing open source solutions, unlike other blockchains designed to be monolithic blocks of highly specialized solutions that are difficult, if not impossible, to improve.

Unparalleled linguistic support

This is how we plan to achieve our unmatched language support, not by reinventing the wheel, but by leveraging the best open source tools that already have an incredible language Support like WebAssembly and Protocol Buffers. WebAssembly (WASM) is what allows us to move much of Koinos’ system logic into smart contracts, as it allows those smart contracts to be executed as if they were implemented natively (in the blockchain it -same). But WASM also has fantastic and ever-growing language support, which will be of great help in enabling developers to write smart contracts in any programming language.

The second technology is what we cover in today’s post and that is Google’s protocol buffers. There are two fundamental innovations that set Koinos apart from other blockchains in terms of scalability and scalability. Koinos is the first blockchain framework built on a microservices architecture, and within that architecture is the first proto-blockchain architectured to rely almost entirely on scalable WASM smart contracts to describe system behaviors (consensus, staking , governance, etc.). Serialization plays an important role in both innovations.

The importance of serialization

In a Koinos node, tiny programs (microservices) send each other countless messages about the blockchain, and the blockchain (one of those microservices) sends messages to the VM (virtual machine). Serialization is how Koinos puts all of these messages into a common format and the way this serialization is done can impact the size of the messages and the speed at which they can move.

“Free” language support

Koinos-Types was the serialization solution we developed specifically for Koinos, so it accomplished everything we needed exactly as we wanted. Koinos-Types is a great solution to the problem, but since it’s a new solution designed specifically for Koinos, targeting new languages ​​is very laborious. In other words, Koinos-Types does not offer us any language support “for free”.

Google’s protocol buffers (Protobuf) have always been a potential solution that we evaluate due to its high performance and fantastic language support. Protobuf is an open source method of serializing data that was developed by Google specifically to be faster and more efficient than existing solutions.

Protobuf gives us a ton of “free” language support, already supporting generated code in Java, Python, Objective-C, C ++, Dart, Go, Ruby, and C #, with more languages ​​to come. There are also third-party implementations available for Erlang, Haskell, JavaScript, Perl, PHP, R, Rust, Scala and same Swift!

Canonical serialization

The problem with Protobuf, and the reason we didn’t use it originally, is that it intentionally doesn’t always serialize data in the exact same way (“canonically”) to maximize flexibility. Technically, Protobuf does not specify deterministic serialization for each type. But when cryptographic integrity is required, it is a responsibility. In other words, we like the language support but don’t like the flexibility of Protobuf for a blockchain.

Enforce canonicity

But even after Koinos-Types was completed, we continued to study Protobuf as a solution as we are always eager to find ways to improve Koinos, even if it means redoing the previous work. What we found was that the serialization of Protobuf was ultimately easy to understand, which made applying canonicity relatively straightforward. Essentially, every field in a Protobuf message must have an integer index which is a natural sort order, and cards are not guaranteed to be serialized in any particular order.

The reason seems to be that not all target languages ​​can guarantee a particular order. For example, Golang deliberately randomizes the iteration order of a card (a higher-order function in a programming language) to prevent developers from relying on a particular order.

Fortunately, the Koinos Blockchain Framework doesn’t need cards, so that’s not a problem for us. From these constraints, the canonical serialization is as follows:

  • Serialize fields in order of field numbers
  • Do not authorize cards

This will primarily affect developers in signing transactions as all messages in Koinos that are cryptographically referenced or verified will be serialized using this serialization.

Support for all languages

When it comes to keeping our promise to support ALL languages, people generally assume that the goal should be to allow developers to write smart contracts in any programming language; however, we do not believe this will actually be the case. The smart contract component within a given application is almost by definition quite small, and the majority of the “big fat” of smart contract development will be done by the Contract Development Toolkit (CDT).

TypeScript smart contracts

While the first CDT we’ll release will be for C ++, that doesn’t mean only C ++ developers will be able to work with it. In fact, it should be accessible to most developers! That being said, a TypeScript CDT would take this accessibility to the ultimate level. A TypeScript CDT will not only be accessible to all developers; it will be easy for them to use. With these CDTs in place, drafting fantastic Koinos smart contracts will be accessible to any developer, and adding additional CDTs can be nice (and something any engineer can develop on their own), but certainly won’t be necessary. because the smart contract is again only a very, very small part of an application.

The vast majority of an application’s code will be level above blockchain, middleware and front-end code. This is where client libraries and microservices will be most useful to developers, and where more diverse language support will add insane value to developers. This is also precisely where Protobuf makes the heavy lifting.

Example of application

Imagine you like building apps using Ruby-on-Rails. Does that mean you need to be able to write smart contracts in Ruby to integrate Koinos? Absolutely not! Interacting with Koinos will mainly involve using client libraries to make the correct API calls and maybe build a microservice that “listens” to relevant transactions needed by the application.

When it comes to client libraries and microservices, Protobuf has already paid incredible dividends! Since we are using RabbitMQ (another open source solution with fantastic language support) for the Koinos message queue, we can already write microservices in any language that has the Protobuf and RabbitMQ libraries. which are virtually all the most popular languages! These include (but are not limited to) Ruby, Java, JavaScript, .NET, Python, PHP, Swift, and Go.

That’s right, thanks to Protobuf, developers of Koinos applications can already write microservices in any of these languages! TODAY!

Client libraries

When it comes to ensuring the availability of high quality client libraries, our experience in the development of Steem has been invaluable. The biggest challenge in writing Steem client libraries was signing transactions.

There are 3 steps to signing a transaction:

  • Serialize the transaction in bytes
  • Sha256 these bytes to get a digest of 256 bits
  • Sign the summary using secp256k1 ECDSA

Obviously, Protobuf will handle serialization and has incredible language support. Sha256 comes from OpenSSL and has a wrapper in pretty much every language imaginable or a suitable replacement. Secp256k1 is the Elliptical Curve Digital Signature Algorithm (or ECDSA) used by Bitcoin and for all intents and purposes already exists in every language we would like to target.

The first step was the main blocking of the Steem client libraries, and Protobuf takes care of it entirely!

As you can see, figuring out how to leverage Protobuf in Koinos will bring incredible long term value to the platform. It took a bit of extra work to get Koinos to work with Protobuf instead of Koinos-Types, but we’re excited to report that internally we’ve completely stopped using Koinos-Types and are relying on Protobuf exclusively for serialization!

This is a big step forward in achieving our goals of enabling developers to work in the programming languages ​​they already know and love, helping Koinos evolve at an even faster pace, and make the most accessible blockchain ever!

Also published here

Profile picture of Andrew Levine Hacker Noon

Key words

Join Hacker Midi

Create your free account to unlock your personalized reading experience.

Source link


About Author

Leave A Reply