Microsoft's blockchain architecture overview explains the evolution as history repeats itself.
Blockchain 1.0 Simple State Machine
In what is referred to as blockchain 1.0 & 2.0, if external data or events based on time or market conditions needs to interact with the blockchain, an “oracle” is required. There is no standard way to supply “oracle” data securely, which can quickly become an issue in multi-party SmartContracts. Calling code or data outside a SmartContract or blockchain in general is breaking the trust barrier threatening the authenticity of the dependent transactions. Cryptlets supply this functionality in Micrososoft's.
Blockchain 2.0 State Machine + Code
RDBMS systems evolved to include logic in the form of stored procedures to assist with more complex data operations. Much like this, distributed ledgers have added a logic tier in the form of Smart Contracts. This code exists alongside the data in the database. This can be thought of as Blockchain 2.0. Ethereum, Eris and others fall into Blockchain 2.0
Blockchain 3.0 State Machine + Code + Cryplets
This added code is called SmartContracts. These SmartContracts operate just like tokenized programs, they have public keys just like any other thing on the network, however they have code and can “do” things like a stored procedure would. SmartContracts offer a lot of promise to create intelligent systems with self-enforcing contracts to allow business processes to operate independently.
When a SmartContract needs to use a Cryptlet, a CryptoDelegate is called using aspects within the smart contract language, like Solidity.
Cryptlets are the principal building blocks for introducing a secure blockchain middleware tier into the architecture. Given the distributed nature of blockchain, this middleware naturally functions as a service in the cloud (Azure/Azure Stack, AWS, Google, Private) and is more accurately called an Application Fabric.
Introducing Project "Bletchley" based on Ethereum. page 