Sergey Nazarov, founder of Wuzhen·Chainlink: Smart Contract 3.0 is a fully integrated smart contract

On the afternoon of November 8, the “2019 World Blockchain Conference·Wuzhen” hosted by Babbitt continued. In the sub-forum “Technology changes the world: the underlying infrastructure of the blockchain”, Chainlink founder and CEO Sergey Nazarov published Connect smart contracts to any under-chain events, privacy protection calculations, and data on the chain.

Sergey Nazarov said that smart contracts have connectivity problems, smart contracts cannot autonomously acquire data and resources outside the blockchain, and more than 80% of smart contract applications need to be connected outside the blockchain. Smart Contract 1.0 is a protocol smart contract, the scriptable smart contract is Smart Contract 2.0 (pass-certified), and Smart Contract 3.0 (all other dapps) is a fully integrated smart contract.

He also pointed out that Chainlink hopes to expand the definition of smart contracts while implementing smart contracts and related events. The smart contract extends from the transfer token to a logic that defines the state of the event. The relationship between the state change logic and related events creates a completely new technology, the oracle that connects external events with smart contracts. .

The following is the live speech of Sergey Nazarov, organized by Babbitt .

Bl (2)

In fact, the essence of our problem is the connectivity problem of the smart contract system. Smart contracts have no way to connect to external databases and cannot use external data, which limits the use of contracts.

We can now generate tokens through blockchains. This is a feature of our industry. It is not that they are willing to make tokens, they are willing to make token-based contracts, but because they can only do tokens now, because When the blockchain is connected to the outside world, it brings us a lot of computational and external problems.

We should use some complicated tokens, or we can use financial products, IoT and other products, we hope to be able to connect with external digital protocols through these new products.

Let's take a look at the progress of smart contracts in history.

Smart contract transition from 1.0, 2.0 to 3.0

For example, we have a very important smart contract advancement – bitcoin's multi-signature, we call it "programmable currency", and, for example, we have to spend months to generate smart contracts, and we now have A smart contract that can be scripted, it is 2.0 of the smart contract. On the other hand, we have to script our contracts, for example, we can use global IoT or trade products, or financial products, to connect with financial products in these outside worlds. If we can't do this, maybe most of our contracts will be just data on the chain or just tokenized data, but it's not useful data in the real world.

We want to be able to solve the problem of smart contracts and external world connections, the most important thing is how we connect the contract with the entire external world.

And Oracle can make our smart contracts do cross-chain. And these features allow our smart contracts to interact with other data, bringing new capabilities to our smart contracts.

Ultimately, we want to generate a new end-to-end architecture, and security is a very important point. If this end-to-end architecture is not secure, we can't have a reliable contract.

Sign a binding agreement between the oracle and the smart contract

A reliable and secure smart contract requires a decentralized contract that can reach a consensus on all copies or copies, and we generate a binding agreement. In fact, on the blockchain, we want it to be a very secure network. And Oracle needs to make such a commitment, all systems generate a reliable commitment, Oracle and smart contracts are tied together by commitment, we have a number of security initiatives, that is, we use decentralization to protect Oracle security. There is a contract between Oracle and the smart contract, and if Oracle fails to fulfill the contract, it will suffer losses.

Let's take a look at the specific details of the problem. The details of the problem are that we have decentralized calculations, it has thousands of nodes, it provides protection, and they are all independent node operators, they all perform the same copy. If we have a single centralized node operator, we have the same pattern. Because we have an end-to-end architecture, our first direction is that we have multiple node operators who execute smart contracts and then save the entire contract, they conduct security assessments and then raise security to a certain level. .

Once we get decentralized data on the oracle, and you get reliable data, you can do decentralization.

For us, inspiring decentralized applications requires us to have a very secure model and a very secure operating environment. In addition, if we do not have these bindings mentioned above, we may suffer other losses. At the same time, we also hope that with such an agreement, these losses can be minimized.

Decentralized finance is fully realized through a decentralized oracle

During the run, our oracle is responsible for unique tasks that add data provisioning, data requests, and critical calculations in a very secure situation.

For us, we can achieve very secure decentralized finance through a decentralized oracle, our customers can trust us, and they can also use our entire mechanism as a reliable and reliable mechanism. At the same time, reliability is not the only goal we have to build. In the future, we will build the entire trust network. We need to build more reliability and security based on more historical data and more active nodes. At the same time, we can also prove its past fairness by accessing data.

So when it comes to the issue of trust, we say that the basis of the past is very important. To this end, we have set up a new platform to establish our security decentralization.

Town Crier: A predictor based on a trusted execution environment


The trusted execution environment not only has a small attack surface, but also achieves confidentiality. The specific performance is as follows:

  1. The node cannot view the operation data;
  2. The data under the chain/operating data is kept secret;
  3. Payment of qualification management to achieve confidentiality;

Under such a mechanism, we can access more nodes and systems while creating better reliability and security.

For us, we must be able to safely extend it to the entire platform for the smart contract issue on the pass. This is our vision. We also want to see which are the most important components of a defense-in-depth strategy.