One Second Layer to Rule Them All
--
Bringing fast and free smart contracts to RSK blockchains
Currently, RSK project (smart contracts for Bitcoin) has two running public networks: testnet and mainnet. Both are connected to Bitcoin networks, to have a 2-way peg using the pair BTC-RBTC. In this way, RSK brings the power of smart contracts to the Bitcoin world.
These days, I was thinking about an idea, that I could write down as a proposal: add a second layer to RSK blockchains, running smart contracts.
The main features should be:
- No gas costs to run smart contracts
- No Proof of Work, but Proof of Stake, with some stakeholders generating and validating the new blocks
- Two-way tokens transfer between this blockchain and RSK blockchain (testnet or mainnet)
- A first implementation deployed to test the idea
- SDK (Software Development Kit) so anyone could add a second-layer blockchain, even having a first implementation
In someway, it is similar to what Loom project brought to Ethereum. Read also Matic Network (Binance Launchpad) and Opinion: How Matic Network Overtakes Loom in the Second-Layer Scaling War
Simplicity pays
One thing that drives this idea, is: simplicity. In this case, don’t alter the product using new technologies, but leverage on existing ones. Instead of state channels or offline payments or something alike, adopt the already tested and proved Ethereum-like blockchain. I think all the features could be provided by a geth implementation.
Why Proof of Stake?
The main reasons to adopt Proof of Stake, are:
- Have a better time to transaction processing and block generation
- Allows to build a world where stakeholders could build they own business or use cases, being the validators
An alternative is to use Proof of Authority. Related posts:
- Why Blockchain Needs Proof of Authority Instead of Proof of Stake
- Proof of Authority Explained
- Proof Of Stake Vs Proof Of Work Vs Proof Of Authority
Token Bridges
The stake of the validators could be based on token property. The token reside in the original network, and could be traded as usual. A gateway could be implemented to transfer such stake token to the second layer blockchain, and back. The stakeholders could gain fee in those transfers, to keep the second-layer blockchain alive, or maybe, the business model resides in other place, where the second layer adds some value to other business.
An example: if you have developed a popular blockchain game, it could be run in the second layer blockchain. User adoption is assured: no complicated on boarding, no fees, no initial gas needed. Only the winners or some activities should be backed up by the original blockchain activity. The velocity of transaction processing allows a better user experience.
Another token bridges could be added, again maybe to support validators with transfer fees. So, a DeFi solution, decentralized exchange, or something similar (simple), could be run in the second layer, and then, the original tokens could be transferred to it, and then, after the operations, return them to the original blockchain. The DeFi ecosystem resides in the main original chain, but maybe, simple operations like exchanges (order-based or pooled-based) could reside in this lightweight second layer.
And these token bridges ARE NOT LIMITED to RSK original blockchains: anyone could add the same functionality to connect this new blockchain to any Ethereum-like blockchain.
I recollected some links about bridges implementations and project in my personal project EthBridge.
I think of two main implementations: token bridge with a external gateway script run by an organization, that reads events in one chain, and do the mirror transfers in the other chain; or similar approach using a federation. To keep simplicity, I would prefer to avoid a decentralized implementation.
Main Implementation and SDK
To allow anyone to deploy and run smart contracts in this kind of blockchain, a main running implementation should be provided. But if anyone considers that it could run a dedicated blockchain, a SDK (Software Development Kit) should be provided.
Angel “Java” Lopez