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.
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.
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.
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.
That’s right, thanks to Protobuf, developers of Koinos applications can already write microservices in any of these languages! TODAY!
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
Create your free account to unlock your personalized reading experience.