Rell 0.8 was a major milestone in the development of Rell. It was released a while ago now, but it introduced new features which are instrumental to Chromia's architecture, and some conveniences which developers have come to expect from modern programming languages. Here we go into a little more depth about one such feature: blockchain dependencies.
Blockchain feature: external keyword allows a blockchain to read data from other blockchains.
Many of Chromia's features stem from an ability to create as many blockchains as needed -- e.g. at least one blockchain per application. But having multiple blockchains completely isolated from each other is not useful. How can we allow multiple blockchains to interoperate and "talk" with each other?
Chromia actually implements several different mechanisms for blockchain interoperation, which are designed for different uses. One of these mechanisms is blockchain dependencies: blockchain A can depend on blockchain B, which allows it to read data directly from B provided that they both reside on the same node.
This mechanism is built directly into Rell syntax and runtime. In code, blockchain dependencies are introduced using the external keyword:
external "user_registry" {
class user (log) { key name; }
}
This declaration would allow an application to read data from user class of user_registry blockchain. The unique identifier of a blockchain will be provided in the application blockchain configuration. Data from other blockchains can be read at any time with no performance penalties, but there are some limitations to maintain determinism and consensus: only immutable data can be read. That is to say, only data from classes with log annotations which make them append-only, and immutable within the constraints of the system.
Internally, Rell and Postchain make sure that these reads are fully deterministic. A block header commits to block identifiers of its dependencies, thus giving the runtime the ability to restrict retrieved data, and making sure that all nodes processing a block now or in future will see the same data.
The blockchain dependency mechanism is the most efficient way to share data between blockchains as it adds no runtime or storage overhead. However, it requires a blockchain and its dependencies to be co-hosted on a node. If every blockchain depended on every other blockchain, it would be no better than a monolithic blockchain as all nodes would have to bear the burden of running all blockchains. For this reason, dependencies are mainly used for reading data from system blockchains. Since every node will have a replica of the system blockchains, this dependency adds no additional burden. Dependencies are also useful when a single blockchain, perhaps acting as a hub of some sort, contains data used by many others.
The main motivation for blockchain dependencies is to enable cross-chain transaction validation to be coded in Rell.
When a blockchain validates a cross-chain transaction, it receives a list of signatures from block producers. It somehow needs to know whether those are actual block producers of blockchain this transaction presumably comes from. Additionally, we might only accept transfers from blocks which are already anchored.
We can solve both problems via blockchain dependencies: a blockchain can read from directory blockchain to get a list of actual block producers at certain height. And it can read from anchoring chain to find if block is anchored. So this whole validation thing becomes just a couple of lines of code.
Implementing validation in Rell makes it more flexible. For example, if an application interacts with private blockchains, it can simply implement custom validation code for them. So it's easy to combine two validation modes (Chromia and private).
We might also use blockchain dependencies for other things within the hierarchy of "system" blockchain.
It is unlikely that we will allow app chains to depend on other app chains in our MVP releases -- this can be easily abused. But potentially it can lead to interesting architecture where you can take data from one blockchain and somehow extend it.