The main difference between Bismuth and Ethereum up until this point was the level of contract decentralization. In Ethereum, contracts were independent and had their own rules. In Bismuth, contract execution was still in the hands of private key owners, requiring some level of trust between participating parties. While Bismuth drastically improved scaling with its client-oriented approach and selective execution, the reliance on the contract executor was a major drawback.
It has been generally overlooked, up until this point, that disadvantages of the Bismuth system can be removed while advantages over Ethereum can remain in place by separating contract execution from the signature mechanism and subjecting it to a specific set of rules, enabling DAO, DeFi and contracts to become genuinely more decentralized than those of Ethereum.
Superiority of the client-oriented approach where consensus on the secondary layer is decided by individual users – as no central authority governs the consensus protocol above the base layer – enables upgrades to the protocol without disrupting existing versions. Therefore, any protocol upgrades can be done in real time and it is only up to users if they decide to accept upgraded versions as they can be running an unlimited number of versions at the same time without any impact on the underlying system.
This is an axiomatic advantage over all existing smart contract platforms including Tezos, which only offers decentralized upgrades to a centralized smart contract protocol, while Bismuth lets users run all protocols at once.
Bismuth does not enforce all nodes to be uniform and see through a single set of eyes. Much more similarly to the real world, the Bismuth model gives every participant the right for their own opinion and the way they see reality. If they choose to not comply with the central vision, they are free to have their own: to change it, upgrade it in any way. This practically results in a complete impossibility of forking, because the system is indifferent towards it. Data is data, saved on the chain. Whatever the user does with it is up to them.
An example of this can be the Bismuth shielded token system, where encrypted data is stored on the chain and makes no sense to those who do not own the keys. However, even those without decryption keys are allowed to transfer those tokens without knowing whether they own them or not, because those with the decryption keys can still see which of the operations are valid and which are not. Shielded tokens are completely decoupled from the core node and the base layer protocol. Upgrading rules to how they or any other contracts are handled has no impact on other users and requires no developer intervention. The truest and final vision of decentralization.
Extending this model to smart contracts is the next logical step and requires only a simple sequence of new rules, decoupled from the base node – requiring no forking. Such contracts can have an unlimited set of rules and commands within. Practical example follows.
Smart contract creation
To create a smart contract system, we first need to establish some basic rules. An initial transaction will be needed, which will describe which tokens the system will be using. For this example, we will use isolated tokens. Integration to the existing token infrastructure is preferable and will require an upgrade of the current token system.
Transaction data:
name:sc01
Transaction operation:
sc-origin
This is everything needed for the transaction itself, because execution rules will be stored in an interpreter. This way, users can choose the interpreter they want to use and they don’t have to share it publicly, allowing for shielded smart contracts without any further effort. You read correct, private contracts by default.
Local contract configuration:
{
'contract_name': 'c01',
'upgradable’: true,
'tokens: '1000000',
'governance': 'token_vote-c01',
'start_block' : '3000000',
'end_block': '3100000',
'allowed_operations': ['sc-payout-c01', 'sc-terminate', 'sc-proposal', 'sc-oracle-vote']
}
‘governance’ defines the ruling mechanic outside of the realm of normal transactions, which are all done with private key signatures. This enables unlimited modes of governance including automatic governance based on blockchain events or coordinated oracle voting, singular oracle authority, etc. “c01” signifies custom particular rules that should not be included in any global set, but that’s all for users to agree on.
‘allowed_operations’ need to be further in Python functions then used by the contract. For example: payout 100 tokens every 50 blocks to the account which received most weighted votes. That would be a simple contract demo. Another demo would be to let users vote on a real world event and then vote on payouts.
Local contract executor:
The contract executor (interpretation engine) scans transactions in the ledger, searching for particular operations which are identified in the local contract configuration. Then it runs particular functions, if those operations are within rules of the contract or have not disabled by voting based on predefined rules (‘sc-proposal’ could serve for contract amendment). For example:
Select all operations “c01“ from the blockchain. Then sort those transactions based on data: proposals, votes. Based on rules set in the contract configuration and functions linked to them, establish whether proposals are valid. Then pass the results of operations to a local database in the same way that aliases or tokens are handled currently in Bismuth. Contracts are directly integrated with oracles as no consensus is enforced.
Further scaling proposal
Due to the nature of these contracts, all data storage can be local, unlimited and fee-less. Even contract rules can be transferred offline, saving on fees and on privacy.
Should users choose to save more data on the blockchain, it is possible to extend scaling by moving them to a decentralized storage system like IPFS and only reference hashes on the blockchain. Every contract executor can then call IPFS and pull the contract data from there. Further research on data availability may be required.
Previous Reference papers
These previous articles can give you more context: