Home > Crypto-finance > Business requirements for smart contract platforms
Business requirements for smart contract platforms
By Alex Kampa, 26 May 2016
On 20 May 2016, I made a presentation at the Blockchain Conference Kiev on business requirements for smart contract platforms during which I presented the general concept of an optimisation consensus protocol.
Here is a brief overview of the main topics that were discussed. The context is that of one (or more) businesses wanting to run a financial Dapp (decentralized application) on a smart contract platform.
Running a business-critical Dapp on a bitcoin-like network of anonymous nodes is not acceptable for most businesses. We need to be able to choose the nodes on which the Dapp will run.
The cost of operating the Dapp must be predictable, and this cost should go down as computing and storage costs go down. Current models of smart contract platforms are not suitable: for example, on Ethereum, users want ETH to go down, speculators want it to go up.
Speed is of critical importance, but transaction optimisation may be resource-intensive. Bitcoin-style POW is not even worth discussing. Even running the same Dapp on multiple nodes seems like a waste. A possible solution is what I call the "optimisation consensus protocol."
Optimisation consensus protocol
Assuming our Dapp has a hard-to-solve (non-deterministic) optimisation problem, it makes sense to try and leverage the distributed processing power of the nodes. We could run the Dapp's optimisation independently on each node, and reach consensus based on the best solution.
Start by using one or more "reasonable" deterministic algorithms that will compute quickly and yield a "baseline result"
Every node independently tries to improve on the baseline result
After spending a predetermined time and/or processing power, the nodes seek consensus: the optimal solution wins
Because it is easy to verify the solution, each node can do it independently
Note the similarity to mining: finding a solution is hard, checking the result is very easy. The key difference is that the problem to be solved is actually relevant to the Dapp we run!
One issue is that each node may not have the same state, i.e. the same set of transactions, account information etc. Attempting to synchronise the state of all nodes before running the optimisation is not realistic. A more realistic solution will be comparing by how much a node has improved over the best of the baseline scenarios.