Jelurida Swiss

One of the main bottlenecks of existing smart contract technology is that it requires every node in the blockchain to process every contract to reach the same state. But is this really necessary?
In Ardor, we implemented a different approach which is more flexible and scalable. Instead of requiring every node to process every contract invocation, we ask only the parties interested in the contract to process it and verify that they reach the same state.
With this approach, the “contract” code itself is a simple Java class uploaded to the blockchain and therefore digitally signed and time stamped. However, the execution of the “contract” is only performed by nodes who selected to run the ‘ContractRunner’ addon.
The input to the contract is typically a transaction with an attached message, which identifies the contract to execute, and supplies optional parameters. The output of the contract are one or more transactions submitted to the network to update the blockchain state. The transactions submitted by the contract are normal transactions which have to comply with all the existing protocol rules.
In other words, the lightweight contract, is Java code which implements a certain interface, stored on the blockchain. The contract code is executed by anyone who wants to run it, not by every node, and is triggered by a blockchain transaction (or by each new block). The result of the calculation made by the contract is submitted as one or more normal transactions of any type supported by Ardor.
What can it be used for? Lightweight contracts provide essentially everything Ethereum smart contracts are used for, integrated with everything Ardor already provides out of the box. Such as automation of repetitive tasks, Financial calculations, Predictable random numbers, Oracles to register information from external sources, and more. All this is integrated with the existing built in Ardor Coin Exchange, Asset Exchange, Voting Tools, Marketplace, Account Properties, Messages, etc. This provides a powerful tool for developing decentralized applications by relying on existing built in API features.
But, how do we make sure that whoever executes the smart contract does not cheat? Since the Java class file is stored on the blockchain, anyone interested can execute the same contract based on the same input, either in production mode, in order to submit the output as a transaction or in approval mode to verify that a transaction submitted by a contract indeed followed the correct calculations.