First published on VOICE in September 2020 -> check it out here.
Block.one has made it crystal clear the company is working on several exciting behind the scenes developments, much of which is strictly confidential and isn’t ready for prime time broadcast. The EOS community can only speculate on what lies ahead, how it will change EOSIO and when it will filter down to the EOS public blockchain. @chaney wrote a great article imagining the future which paved the way for a range of questions that were put directly to Dan on the longest-running EOS podcast, EverythingEOS! The interview referenced so many topics, providing great insight into the ideas which are driving Dan, block.one and EOSIO development.
While we can’t yet dive inside the super-secret block.one GitHub repositories, we can view the ongoing public development and envisage future capabilities and Use cases. The EOSIO public codebase is continuously under development. In the last month, there were 26 contributors to the repository, 71 merged changes, and 13 issues closed or bugs squashed.
Add to this a steady stream of documentation, code examples, resources and testnet updates; things are moving. It’s hard to understand why the dollar price of the flagship EOS public blockchain is stagnant when there is substantial technological advancement. Block.one is pioneering the regulatory path, while the community is building and optimising. At some point, the price curve should catch or exceed the innovation curve, reflecting actual underlying value. Many articles cover the EOS price so I won’t go into it any further.
What can the EOSIO repository on GitHub tell us?
In May, @matthewdarwin from EOSNation shared a screenshot of working changes to EOSIO GitHub Repo. At the time, I speculated such an update could be related to Inter-Blockchain Communication (IBC), which Dan confirmed soon after.
In recent interviews, we’ve heard more about IBC. We know its related to Bitcoin, possibly Ethereum and will certainly work with other EOSIO based chains.
So what led me to IBC? Why did this Pull Request suggest IBC as one of the core use cases? The answer is AMQP or Advanced Messaging Queue Protocol. For those who aren’t familiar here’s a summary from cloudampq.com.
“Advanced Message Queuing Protocol (AMQP) is created as an open standard protocol that allows messaging interoperability between systems, regardless of message broker vendor or platform used; With AMQP, you can use whatever AMQP-compliant client library you want, and any AMQP-compliant broker you want. Message clients using AMQP are completely agnostic.”
AMQP is an open standard protocol for sending messages between systems. In modern application architectures, messaging systems like RabbitMQ, Kafka or the cloud variants are relatively standard, as they enable loosely coupled components to talk over a private network or the internet. The concept of messaging is not new. The big idea is an app creates or produces a message and broadcasts it onto a bus or queue. Interested parties listen or consumers message and process the message data independently.
How does this tie into eosio? If you’ve ever deployed eosio, you’ll have noticed the software is plugin based. For example, you could deploy a configuration file with the following plugins.
config.ini
...
plugin = eosio::http_plugin
plugin = eosio::chain_plugin
plugin = eosio::chain_api_plugin
plugin = eosio::db_size_api_plugin
plugin = eosio::history_plugin
plugin = eosio::history_api_plugin
plugin = eosio::net_plugin
...
For a full list of plugins visit https://developers.eos.io/manuals/eos/latest/nodeos/plugins/index
The eosio update suggests two new plugins are in the process of development and will conceivably be merged into the codebase. These are the amqp_trx_plugin & amqp_trace_plugin. The following diagram aims to demonstrate how apps may use the new plugins once released. Please be aware I’m speculating on what’s publicly available, and major changes are possible down the line.
Apps publish messages into a message exchange which writes transactions to the trx queue. The plugin architecture of nodeos accepts the transaction for speculative execution. In my single node example, nodeos stores the transaction in RAM, which is either in local memory or the local instance of RocksDB on the hard drive, but that’s a topic for a future article.
If an application developer, exchange or business chooses this architecture, they write their transactions locally using the AMQP method. If connected to other networked nodes, new transactions get broadcast to others and eventually get included in a block as per the typical flow.
Imagine a world where instead of randomly assigning app names we use these blockchain networks.
You now have a communication channel between Bitcoin, Ethereum and other EOSIO networks. It means EOSIO and EOS itself, can listen for transactions on other networks and react to events, sending data between contracts. Event-driven architectures are extremely powerful, as it means blockchains can react to events that occur in the real world.
This solves the problem of getting transactions into EOSIO based chains, but leaves me with questions about how to extend the model to feed data in the other direction? I suspect the answer lies hidden inside the super-secret private Block.one repository and we’ll need to wait to see just how that plays out.
That concludes part 1 of the series, stay tuned for future articles.
