Overcoming blockchain limitations
EVM-powered blockchains were designed to support higher complexity in code execution, meaning that they natively empower smart contracts. Still, while designing DApps you have to deal with some blockchain limitations.
Specifically on Ethereum (which today is the “state of the art” smart-contract-capable blockchain platform), one of the main pain points is the “gas limit”. When executing a smart contract each operation comes at a cost, whose amount is measured with a specific unit called “gas”, to be paid by the party initiating the transaction. The more complexity your smart contract has to handle, the more gas you will end up spending. However, due to security reasons there is an upper limit in the amount of gas which can be executed in the set of transactions we want to include in a block — this is the above-mentioned “block gas limit”.
Another pain point is the impossibility to execute complex operations on the Ethereum Virtual Machine due to some other constraints like the missing support for floating point arithmetic operations.
Last but not least, as a consequence of the EVM having its own set of opcodes and higher level languages (Solidity, Serpent, LLL, …) there is no direct access to advanced libraries which many complex applications would need to use. Looking for example at the financial industry, applications have a strong need to reuse mature financial libraries, algorithms and data which the blockchain has no direct access to. Even with access, there would be no space to execute those operations on-chain due to the above-mentioned “gas limit” and the lack of floating-point arithmetics.
In order to address the issues listed above, delegating some specific portions of the smart contract execution to an off-chain mechanism would make a much broader set of applications viable.
By enabling the auditable execution of a given application into a secure blockchain-unrelated (off-chain) context, the computation datasource we designed aims to solve those very issues. Delegating some operations to an off-chain program might be the way to have more flexible applications both in terms of complexity and variety of libraries available. Still, this should not compromise the transparency features introduced by the blockchain — this means the auditability of the off-chain part is as important as the auditability of the on-chain part provided by the blockchain by design.
The secure execution of the delegated code is granted via cloud computing platforms (specifically, Amazon Web Services), where a stateless throw-away Virtual Machine is set up every time a computation query is calling Oraclize. While leveraging Amazon Web Services for a code execution, a concern is represented by the possibility of an Amazon employee phisically accessing the Virtual Machine and tampering with the result. To reduce the risk of “rogue” interference or alterations arising from Amazon, we chose a stateless approach, which uses strict time contraints to hinder an attacker.
Additionally, we give further security guarantees on the authenticity of the delivered result. Oraclize, being the intermediary between the off-chain context and the smart contract, could potentially tamper with the result of the computation. The authenticity proofs were designed to address this specific problem — those cryptographic proofs are, in this specific case, proving that the result of an off-chain computation was not tampered with during the delivery and that the code execution really happened in a fully lock down instance where Oraclize (or any other party) could not interfere with the expected code execution.
The computation datasource enables and facilitates a whole new set of decentralized applications to come to life. The use of this tool is particularly important in the specific context of banking, trading or insurance applications, as it enables a combined on-chain and off-chain approach — meaning that those applications can leverage blockchain features with no need to give up on traditional tools and libraries.
Paypal example use-case
Moreover, the computation datasource facilitates the interaction with traditional payment systems, as it enables smart contracts to be paid via common (non-cryptocurrency) payment methods. We prepared sample use-case code showing the interaction with Paypal.
As a DApp developer, you might want the users to pay for a service by using traditional payment methods. As soon as a user initiates the Paypal payment, what happens behind the scenes is the smart contract calling the Oraclize computation datasource. In this case, this environment is used to execute the whole payment process from payment initiation to verification of the payment execution.
While keeping the core execution on the blockchain, the delegation of some logics allows to leverage the higher flexibility offered by a non-blockchain environment. The computation datasource, being it some sort of blockchain-extension, really allows smart contracts to get the best of both worlds.
Note: The company has now rebranded into Provable.