Blockchains on Blockchains: Smart Contracts on Saito

Imagine we want to scale Ethereum without plasma chains or chains-of-chains. Here is one strategy:

Start by creating a Saito module that selects nodes through some algorithm. All nodes running this module listen on the Saito network for transactions that are sent to a particular address. They save them in a private mempool. And when the algorithm permits, whatever node is selected bundles all of these transactions into a block, which it publishes by including the JSON representation of that block in another base-layer Saito transaction which is picked up by all of the modules on the network.

Congratulations! We have created a blockchain that runs atop another blockchain. This might seem useless at first glance, but note that because our blockchain is operating atop Saito it keeps the security and scalability of the underlying Saito chain no matter how few nodes are actually running its module. And because turning a blockchain into a smart contract system is as simple as adding a virtual machine to our module, we now have the ability to create smart contract platforms that remain secure even if they only have a few participants executing these contracts.

The problem with this approach is economic: unless the nodes collect payments separately, they do not have any source of revenue while posting messages on Saito does have some trivial cost. We could hypothetically make it profitable for nodes to participate if our meta-blockchain manages its own token, but forcing users to deal with TWO tokens introduces pricing attacks and is frankly rather inconvenient. It would be better to have a simpler solution, and — in the case of Ethereum — one that lets users pay entirely in ETH.

One possible way to keep everything priced in Ethereum is asking the nodes that wish to create an off-chain virtual machine to register their public keys with an on-chain Ethereum smart contract. Once that is done a multi-sig Saito address can be generated that can be independently verified by the public. And whenever a user wishes to interact with an off-chain smart contract, they can query the Ethereum network to figure out (1) the address to which transactions must be sent, (2) whether that platform is still active, and (3) any additional information we wish to track such as the cost of contract execution, a hash representation of the state of the virtual machine, and more.

And how do participants get paid? Users can now simply make a payment to this multisig address when submitting instructions for execution. So our modules now listen for transactions as before. And block production takes place exactly as before. The only change is that each time a block is produced, the block-creator must also (1) include a transaction that withdraws his share of the payments, and (2) sign whatever previous withdrawal requests still lack adequate signatures to pass the N-of-M withdrawal threshold. After N-of-M confirmations block creators will thus be able to withdraw their payments, yet we have avoided timing and exchange attacks here because any chain reorganization that rolls back our outbound payments also rolls back our inbound payments.

The result is the ability to create transient smart contract platforms that can be run by as few or as many machines as we like and which can offer configurable amounts of memory and processing power. And best of all, with Ethereum payment channels operating natively on the Saito blockchain the entire process of interacting with these contracts can be done directly in the native Ethereum token from the perspective of the user.

What we have created is something interesting and new. As unlike with plasma chains and chain-of-chain approaches, there is no risk of mass exit and cascading failures with these sorts of virtualized meta-VMs. From the user perspective, the only risk is that they might send a transaction to an outdated address, although this problem can be avoided either by monitoring the underlying Ethereum contract. And unlike other smart contract platforms, there remains a key role for the Ethereum network, which becomes akin to a control panel that manages a constellation of machines that create upper-layer virtual machines on demand according to whatever level of security, decentralization and processing power is required for their particular use case. If desired, the Ethereum contract layer can even enforce penalties on participants who refuse to carry out their block-production / smart contract execution duties on the upper-levels.

And from an economic approach? Perhaps the most interesting thing about this approach is that it complements Ethereum in its limitations. Whereas Ethereum must limit the pool of nodes that are eligible for bandwidth and storage payments (or face risk of sybil attacks), Saito is happy to pay for storage and bandwidth but must limit payment for smart contract execution. The free-rider problem that imposes scaling constraints exists in both chains, but they affect exactly the opposite set of nodes in each network, which is why the method is ultimately so complementary.