
Chinese: 
 
大家好，我是Ari Juels。
今天很高兴能作为Chainlink新任的首席科学家参加SmartCon
今天很高兴能作为Chainlink新任的首席科学家参加SmartCon
我今天尤其感到开心
因为我会跟大家聊聊DECO，我们今天早前也宣布了收购DECO的消息
因为我会跟大家聊聊DECO，我们今天早前也宣布了收购DECO的消息
DECO是我在IC3康奈尔大学研发的一项技术，这项技术刚被Chainlink收购了
DECO是我在IC3康奈尔大学研发的一项技术，这项技术刚被Chainlink收购了
我想跟大家讲讲DECO的具体内容
先来看一个案例
这两个是加密学家举例时最常提到的人
Alice和Bob
Bob要发布一个新通证
叫做BBT（Bob's Bubble Token）
然后他要销售通证
他有特别的方法保障通证销售机制是公正合理的
他有特别的方法保障通证销售机制是公正合理的
他想保障通证的分配是公平的
不会被人恶意囤积

English: 
(upbeat music)
- Hello, I'm Ari Juels.
I'm delighted to be with
you here today at Smart Con
in my new role as Chief
Scientist of Chainlink.
In fact, I'm doubly delighted
because as was announced earlier today,
I'm gonna talk about DECO,
a technology developed in my separate role
at Cornell Tech in IC3 that
Chainlink has just acquired.
To explain what DECO is,
let me first give you a motivating example
involving cryptographers'
two favorite people,
Alice and Bob.
Now Bob is about to launch a new token
called Bob's Bubble Token,
and he's gonna be holding a token sale.
Bob has particular ideas
about how to make his
token sale responsible.
He wants to ensure that his
tokens are fairly distributed.
They're not all snapped
up by Will for instance,

Chinese: 
而参与者可以以合理的价格持有通证
而参与者可以以合理的价格持有通证
因此他设置了以下规则
如果你要购买100个BBT
必须出示显示你名字的银行账户，而且账户中必须至少有5千美元
必须出示显示你名字的银行账户，而且账户中必须至少有5千美元
这样一来就很难伪造身份
这样一来就很难伪造身份
同时这也是一种身份认证
不用担心匿名的问题
那么现在Alice很想要购买这个非常有潜力的通证
那么现在Alice很想要购买这个非常有潜力的通证
因此她在网上登录了银行账户查看了一下余额
因此她在网上登录了银行账户查看了一下余额
她发现她的账户余额超过了5000美元
她发现她的账户余额超过了5000美元
所以就去跟Bob说
“哈喽，我银行账户余额超过5000美元”
接下来Bob肯定会问：“你怎么证明呢？”
接下来Bob肯定会问：“你怎么证明呢？”
那么Alice这么向Bob证明她银行账户里至少有5000美元呢？
那么Alice这么向Bob证明她银行账户里至少有5000美元呢？

English: 
and that people who participate
can reasonably afford to do so.
So he sets the following rule.
So buy up to 100 BBT,
you have to show that
there's a bank account
with your name on it, that
contains at least $5,000.
This makes it hard for people
to create fictitious identities.
And it's also a kind of accreditation.
We won't worry about
concealing names at this point.
Now Alice would very
much like to participate
in this most promising of token sales.
So she logs into her bank account online
and checks her balance,
and she discovers lo and behold
that she has more than $5,000.
So she goes to Bob and says,
"Hi Bob, I've got more than
$5,000 in my bank account."
Naturally Bob's response is the question,
"Can you prove it?"
So how can Alice prove to Bob
that she has a bank account
with at least $5,000 in.

Chinese: 
首先Alice可以把银行账户余额页面截一个图发给Bob
首先Alice可以把银行账户余额页面接一个图发给Bob
但这就会出现一个问题
这个截图是很容易用P图软件做出来的
这个截图是很容易用P图软件做出来的
Alice可能账户里根本没有钱
但假装是有钱人
所以截图这个办法肯定是行不通的
另一个办法是Alice向Bob发送她的登录信息，用户名和密码
另一个办法是Alice向Bob发送她的登录信息，用户名和密码
另一个办法是Alice向Bob发送她的登录信息，用户名和密码
Bob登录进她的账户查看余额
Bob登录进她的账户查看余额
这个方法看似是行得通的
但如果Alice希望将余额一直保持在5000美元以上，每次都把密码交给别人也是不行的
但如果Alice希望将余额一直保持在5000美元以上，每次都把密码交给别人也是不行的
所以这个方法也行不通
然而我们发现，Alice每次登录银行网站时几乎都会用HTTPS
我们发现，Alice每次登录银行网站时几乎都会用HTTPS
然而我们发现，Alice每次登录银行网站时几乎都会用HTTPS
也就是说她通过TLS协议与银行建立了安全的连接
也就是说她通过TLS协议与银行建立了安全的连接
这个TLS协议是互联网通用的数据安全协议

English: 
First idea is for Alice
to take a screenshot
of her bank account
balance and sent it to Bob.
But this is a problem.
And that it's relatively
easy to modify a screenshot
using say, Photoshop.
Alice might have no money in her account,
and yet pretend to be a multimillionaire.
So clearly this isn't gonna work.
Another possibility is that
Alice sends her login credentials,
her username and password to Bob.
Bob then logs into her accounts
and checks her account balance.
Now this works,
but it's a bad habit for Alice to get into
if she wants to keep her bank
account balance above $5,000.
So that's not quite gonna work.
We observe though
that when Alice logs
into her bank's website,
she's almost certainly using HTTPS.
This means she's establishing
a secure connection
with the bank via TLS.
That's the protocol that's
used everywhere on the internet

Chinese: 
这个TLS协议是互联网通用的数据安全协议
在TLS协议中，服务器会发给Alice一个证书，验证公钥中的身份信息
在TLS协议中，服务器会发给Alice一个证书，验证公钥中的身份信息
在秘钥交换协议或握手过程中，会在消息上附上电子签名
在秘钥交换协议或握手过程中，会在消息上附上电子签名
这是一个很好的机制
特别是使用电子签名
所以Alice应该也可以使用TLS协议向Bob证明她的银行余额
所以Alice应该也可以使用TLS协议向Bob证明她的银行余额
所以Alice应该也可以使用TLS协议向Bob证明她的银行余额
但TLS存在一个问题
它确实会使用公钥加密技术以及数字签名交换秘钥
它确实会使用公钥加密技术以及数字签名交换秘钥
但是它交换的是会话或记录层的对称秘钥
但是它交换的是会话记录层的对称秘钥
换句话说
当在Alice和服务器之间交换数据时，使用的是双方共享的秘钥保障安全
当在Alice和服务器之间交换数据时，使用的是双方共享的秘钥保障安全
这个秘钥称作MAC
全称是消息认证码
而这个MAC并非真正的签名

English: 
to secure data.
In TLS, the server presents
Alice the certificate
validating its identity in a public key.
And in the course of the
key exchange protocol
or the handshake, it's
digitally signing a message.
This is all well and good,
especially the use of digital signatures.
And it seems like we might
somehow be able to leverage TLS
to solve our problem
of authenticating Alice's
bank account balance to Bob.
But there's a problem with TLS.
It does indeed use public key cryptography
and digital signatures
to perform key exchange,
but this is to exchange
symmetric keys for the session
for what's called the record layer.
In other words,
when data is exchanged
between Alice and the server,
it's secured using a key
that the two of them share.
They're using what's called a MAC
or a message authentication code
rather than the true signature.

Chinese: 
因此，Alice跟银行一样都可以对数据进行签名
因此，Alice跟银行一样都可以对数据进行签名
银行或服务器的数据没有电子签名，无法向第三方证明数据的真实性
银行或服务器的数据没有电子签名，无法向第三方证明数据的真实性
银行或服务器的数据没有电子签名，无法向第三方证明数据的真实性
有人提议修改TLS协议
比如苏黎世高工的研究人员提出的TLS机制
还有像open ID这样的机制，可以签名部分数据
但总的来说，如果要实现我们的愿景
也就是在预言机网络中实现广泛的数据签名
就需要对基础架构做非常大的更改，甚至有些是不切实际的
就需要对基础架构做较大的更改，甚至有些是不切实际的
因为有保密性的限制，数据仅有电子签名还不够
因为有保密性的限制，数据仅有电子签名还不够
之后我们会详细讲到这一点
那么回到这个案例
将TLS数据转发给Bob跟截图一样都行不通
因为Alice跟服务器一样都有权限对数据签名
因为Alice跟服务器一样都有权限对数据签名

English: 
Consequently, Alice is just
as capable of signing data
in this sense at least, as the bank is.
There's no digital signature
on data that can be shown
to a third party to provide
trustworthy proof about the data
provided by the bank or
the server in this case.
There are proposals to change TLS
like the very nice TLS
scheme from ETH Zurich
and schemes like open ID, sign some data,
but in general, to get the
kind of widespread data signing
we'd like to have for an oracle network
would require a big
infrastructural changes
and practical ones.
And in fact, digitally
signing data isn't good enough
because of confidentiality requirements
as we'll see in just a moment.
So to summarize here,
forwarding TLS data to Bob is
no better than a screenshot.
Again, because Alice is just
as capable of signing data
as the server is.

Chinese: 
最后，web服务器里会有许多无法使用的隐私数据
最后，web服务器里会有许多无法使用的隐私数据
比如银行账户余额和身份认证信息
以及驾照、企业内部数据或内部API接口等各种数据
以及驾照、企业内部数据或内部API接口等各种数据
这个情况让预言机开发者感到十分苦恼
因为这些数据都被锁起来无法使用
于是我们发明了DECO系统解决这一问题
DECO的目的是解锁这些数据
在区块链系统或其他系统中使用
特别是使用这些数据通过TLS协议登录网站
特别是使用这些数据通过TLS协议登录网站
使用零知识证明向验证者证明收到数据的状态
使用零知识证明向验证者证明收到数据的状态
比如说在刚才提到的案例中
Alice需要能够向Bob证明她账户里余额超过5000美元
Alice需要能够向Bob证明她账户里余额超过5000美元
而且最好不用披露她账户里到底有多少余额

English: 
As a result, there's lots
of unusable private data
sitting in web servers.
Things like bank account balances
and identity information,
identity documents like driver's licenses
and private enterprise
data or private APIs.
This situation is really
frustrating for oracle builders.
Having data locked up
this way is a frustration.
Our solution to this problem
is this system called DECO.
What DECO aims to do is
liberate this data if you will.
So it can be used in blockchain
systems and elsewhere.
Specifically, we want to use it
to be able to log into a website via TLS,
and then prove statements
about the data she receives
to a verifier using zero knowledge proofs.
For instance, in our banking example,
we'd like Alice to be able to prove to Bob
that she has more than
$5,000 in her account,
ideally without even revealing
her bank account balance.

English: 
And we would like to do
this with no modification
to the server.
That way we can build on
a seen infrastructure.
But wait a minute, didn't I
just say the TLS can't do this?
I did, but DECO sidesteps
the limitations of TLS
using some tricks that I'll explain.
So let's take a glimpse
under the hood of DECO.
Let me spend a few minutes
explaining how it works.
You don't need to understand
any of this explanation
to grasp what DECO does,
but I'd like at least
to convey some flavor
of its mechanics.
The key idea is something we
call a three-party handshake.
And explaining what that is,
I'm gonna refer to Alice
and Bob alternatively,
as the prover and verifier,
because those are the roles
that they'll be playing
in the protocol here.
When Alice or the prover
logs into a website,
the session key she
establishes with the server
is going to be split on the client side
between the prover and verifier.

Chinese: 
同时不用对服务器做任何修改
同时不用对服务器做任何修改
这样我们就可以在遗留基础架构上进行开发
但等一下，我刚刚不是说过TLS协议行不通吗？
对我确实这么说过，但是DECO打破了TLS的限制
具体用的方法我待会会详细解释
我们先看一下DECO背后的机制是什么
我先花几分钟的时间讲一下DECO的运作机制
其实就算你不理解它的运作机制也不妨碍你理解它的功能
其实就算你不理解它的运作机制也不妨碍你理解它的功能
但我还是想要跟大家简要分享一下这项技术背后的原理
但我还是想要跟大家简要分享一下这项技术背后的原理
核心机制是“三方握手”
这里我还是要用Alice和Bob两个人举例，Alice是证明者，Bob是验证者
这里我还是要用Alice和Bob两个人举例，Alice是证明者，Bob是验证者
这里我还是要用Alice和Bob两个人举例，Alice是证明者，Bob是验证者
他们在这个协议中将扮演这两个角色
他们在这个协议中将扮演这两个角色
当Alice（证明者）登录网站时，
她与服务器建立的会话秘钥会在客户端被分成证明者和验证者两部分
她与服务器建立的会话秘钥会在客户端被分成证明者和验证者两部分
她与服务器建立的会话秘钥会在客户端被分成证明者和验证者两部分

Chinese: 
Alice和Bob分别持有这个会话秘钥的一部分，加在一起能构成完整的秘钥
Alice和Bob分别持有这个会话秘钥的一部分，加在一起能构成完整的秘钥
Alice和Bob分别持有这个会话秘钥的一部分，加在一起能构成完整的秘钥
他们俩都不知道完整的秘钥
为了要实现这一点
证明者和验证者需要以某种特殊的方式交互，这个我待会会详细讲
证明者和验证者需要以某种特殊的方式交互，这个我待会会详细讲
我不会详细讲整个协议
因为协议内容非常复杂
但是我会描述其中一个部分
让大家大致了解它的运行机制
通常TLS协议交互秘钥时，客户端会随机生成一个私钥
通常TLS协议交互秘钥时，客户端会随机生成一个私钥
我们称之为X
然后客户端会计算对应的公钥Y
并将Y或Yclient发送给服务器
并将Y或Yclient发送给服务器
而DECO的机制是这样的
验证者首先随机生成自己的私钥Xv，计算公钥，并将公钥发送给证明者
验证者首先随机生成自己的私钥Xv，计算公钥，并将公钥发送给证明者

English: 
The session key, this all critical key,
is gonna be equal to the sum of shares
held by Alice and Bob.
Neither of them will know
the key in its entirety.
In order to make this happen,
the prover and verifier need to interact
in a way I'll describe.
Now I'm not gonna describe
the full protocol,
which is pretty complicated,
I'm just gonna describe a tiny piece
to give you some intuition
for how it works.
In a normal TLS key exchange,
the client randomly
generates a private key,
which we'll call X.
She then computes the
corresponding public key Y,
and she sends this to the server.
This Y or Yclient.
In DECO, what happens
is something like this.
The verifier first generates
his own private key,
Xv at random, computes the public key

English: 
and sends that corresponding
public key to the prover.
The prover then generates
her own private key Xp
and computes the
corresponding public key, Yp.
And what she sends to
the server is the product
of her public key and the
verifier's public key.
Thanks to an additive homomorphism here,
the private key X
corresponding to Yclient,
the public key sent to the server
is exactly the sum of the
private key of approver
and the private key of the verifier.
So we've split the private key here.
Now, again, this is only one tiny piece
of the larger protocol.
The full protocol is much more involved
because then the value
X needs to be converted
into a symmetric session
K and so on and so forth.
But what I've presented here is enough
to get the basic idea.
So the intuition is that Alice and Bob
generate this shared
key K, the TLS session,

Chinese: 
验证者首先随机生成自己的私钥Xv，计算公钥，并将公钥发送给证明者
然后证明者生成自己的私钥Xp，计算出对应的公钥Yp
然后证明者生成自己的私钥Xp，计算出对应的公钥Yp
最后将她自己的公钥和验证者的公钥得出的计算结果发送至服务器
最后将她自己的公钥和验证者的公钥得出的计算结果发送至服务器
这里使用了加法同态加密技术
与Yclient对应的私钥X（Yclient就是发送至服务器的公钥）
与Yclient对应的私钥X（Yclient就是发送至服务器的公钥）
等于证明者私钥与验证者私钥相加的总和
等于证明者私钥与验证者私钥相加的总和
所以这里我们将私钥分为两个部分
这里我要强调一下，这只是最协议的一个粗略概述
这里我要强调一下，这只是最协议的一个粗略概述
完整版的协议内容更加详细
比如X值需要被转换成对称会话秘钥K等等
比如X值需要被转换成对称会话秘钥K等等
但我刚刚所说的基本上覆盖了协议的大致思路
但我刚刚所说的基本上覆盖了协议的大致思路
所以整体思路就是Alice和Bob针对TLS会话生成共享秘钥K
所以整体思路就是Alice和Bob针对TLS会话生成共享秘钥K

English: 
and they use this shared key
in a joint manner, securely.
They can do things like
decrypt data for Alice.
The protocol is such that
Alice can't forge data
from the server,
because she doesn't know the
session key at a critical time,
but she can prove things
about the data provided
by the server to Bob in zero knowledge.
And all of this again is
transparent to the server.
The server doesn't see any
of this stuff shaded in gray.
It has no idea that there's
an interactive protocol
happening on the back end.
As far as it's concerned,
it's talking to a
perfectly ordinary client.
All of this gives us a
refined picture of DECO,
involves two steps.
First, the user logs
into the target website
while performing a three-way
handshake with a verifier,
proven verifier.
And then the prover can prove
things in zero knowledge

Chinese: 
他们以安全的方式共同使用这个秘钥
比如为Alice解密数据
这个协议保障了Alice无法篡改服务器的任何数据
这个协议保障了Alice无法篡改服务器的任何数据
因为她无法得知会话秘钥
但是她可以通过零知识证明向Bob证明服务器数据的真实性
但是她可以通过零知识证明向Bob证明服务器数据的真实性
这些对服务器都是透明的
服务器看不到这里灰色的部分
服务器并不知道后端设立了一个交互式协议
服务器并不知道后端设立了一个交互式协议
对服务器来说，它只是在与一个普通的客户端交互
对服务器来说，它只是在与一个普通的客户端交互
这就让我们能更清楚地了解DECO的运行机制
其中包括两个步骤
首先，用户登录目标网站
证明者与验证者展开三方握手
证明者与验证者展开三方握手
证明者通过零知识证明来向验证者证明从服务器获得的数据是真实可靠的

Chinese: 
证明者通过零知识证明来向验证者证明从服务器获得的数据是真实可靠的
那么在一个完整的预言机网络中如何使用DECO呢？
假设有一组预言机节点，或Chainlink节点
假设这是在Alice要证明银行账户余额超过5000美元之前
假设这是在Alice要证明银行账户余额超过5000美元之前
那么就很简单
她只需要从这三个节点生成DECO证明，分别向每个节点证明她银行余额超过5000美元
她只需要从这三个节点生成DECO证明，分别向每个节点证明她银行余额超过5000美元
她只需要从这三个节点生成DECO证明，分别向每个节点证明她银行余额超过5000美元
然后节点可以使用门限签名或其他技术共同签署一份报告
然后节点可以使用门限签名或其他技术共同签署一份报告
表明它们已经收到了有效证明
而由于Alice使用了零知识证明，
而由于Alice使用了零知识证明，
因此不需要向预言机直接披露她的银行余额
因此不需要向预言机直接披露她的银行余额
除了Alice以外的任何其他人只知道她的银行余额是超过5000美元的
除了Alice以外的任何其他人只知道她的银行余额是超过5000美元的
我现在还想谈谈DECO应用在预言机网络中的其他案例
我现在还想谈谈DECO应用在预言机网络中的其他案例
我现在还想谈谈DECO应用在预言机网络中的其他案例

English: 
about the data she gets from
the server to the verifier.
How then do we use DECO in
a full blown oracle network?
Suppose we have a set of
oracle nodes, chain link nodes.
And suppose this before that Alice
wants to prove that her bank
account balances about $5,000.
It's very simple.
All she needs to do is
generate DECO proofs
for these three nodes, proves
to each of them individually
that her balance is about $5,000
and they can then collectively
using a threshold signature
or whatever you like sign a report
saying that they saw a valid proof.
And of course Alice,
because of the use of
zero knowledge proofs,
doesn't need to show her account balance
directly to the oracle nodes.
All they learn or anyone learns
is that her account
balance is about $5,000.
But now I'm going to talk about
three other different example applications
that illustrate how DECO can
be used in an oracle network.

English: 
The first such example is
private enterprise data.
Let's take a supply chain example.
Now enterprises wants to
connect to blockchains,
but have concerns about confidentiality.
And this example is meant
to illustrate the point.
Alice is responsible in this example
for shipping some goods.
We'd like to take advantage of
the power of smart contracts
by having her paid automatically
when the goods arrive.
But there's a critical
confidentiality issue here.
The goods are say some rare
and highly valuable commodities
that are nearly impossible to
get during the COVID-19 era.
So she doesn't wanna advertise on chain
that she's shipping them.
Something like say kittens,
or maybe that's too implausible.
Nobody can get a kitten these days.

Chinese: 
第一个应用场景是企业内部数据
比如说供应链中的数据
有些企业希望接入区块链
但是又担心保密性问题
我接下来要讲的这个案例就是围绕这个问题展开的
这个案例中，Alice负责发货
这个案例中，Alice负责发货
我们想要利用智能合约，在货物送达时自动付款给她
我们想要利用智能合约，在货物送达时自动付款给她
但是现在存在一个很重要的问题，那就是保密性
这批货物是稀有的高值商品
在新冠肺炎期间几乎没人能弄到
所以她不想要在链上广播她发货的具体内容
所以她不想要在链上广播她发货的具体内容
假设她发出的是一群小猫咪
不过这有点不切实际了
现在简直是一猫难求，小猫咪太金贵了

Chinese: 
所以咱们还是换成金条吧？
Alice不想在链上披露或向节点披露她要发送两吨金条
Alice不想在链上披露或向节点披露她要发送两吨金条
Alice不想在链上披露或向节点披露她要发送两吨金条
所以发货具体细节可以用加密技术隐藏起来
所以发货具体细节可以用加密技术隐藏起来
我们把它表示为C
Alice通过“Bob的大船运输服务”运送金条
Alice通过“Bob的大船运输服务”运送金条
她需要从“Bob的大船”中获得金条运输数据并以可信保密的方式发送至智能合约
她需要从“Bob的大船”中获得金条运输数据并以可信保密的方式发送至智能合约
她需要从“Bob的大船”中获得金条运输数据并以可信保密的方式发送至智能合约
她需要从“Bob的大船”中获得金条运输数据并以可信保密的方式发送至智能合约
各位可以清楚地看到DECO在这个场景中发挥的价值
Alice登录Bob的网站
在预言机系统中执行DECO，证明合约中约定的运输货物按C值已经送达
在预言机系统中执行DECO，证明合约中约定的运输货物按C值已经送达
在预言机系统中执行DECO，证明合约中约定的运输货物C值已经送达
然后就搞定了
另外你还会发现
由于这里使用了零知识证明

English: 
So let's say gold bars, right?
Alice doesn't wanna reveal on chain
or to the oracle nodes, that
she's shipping say two tons
in gold bars.
So the shipment details can be represented
in some cryptographically
concealed form in the contract.
We'll call this representation C.
Now Alice is shipping these bars
using a service called Bob's Big Boats.
Somehow she needs to get data
about the shipment of the gold bars
from Bob's Big Boats to the contract
in a trustworthy and confidential way.
You can easily see how she
can use DECO for this purpose.
She logs into Bob's website,
executes DECO with the oracle network
to prove that the shipment
specified on the contract
in that critical value C has arrived.
And that's it.
And you'll observe that again
because of the use of zero
knowledge proofs here,

Chinese: 
没人能知道Alice运输了金条
而且所有关键的细节也都被隐藏了
第二个例子就是我们常提到的去中心化身份认证
第二个例子就是我们常提到的去中心化身份认证
假设Alice想要从银行贷款
需要证明她年满18，这是贷款审批的其中一个要求
需要证明她年满18，这是贷款审批的其中一个要求
她可以使用DECO生成证明
登录记录她出生证明的权威网站
登录记录她出生证明的权威网站
并使用DECO向预言机网络证明她年满18岁
并使用DECO向预言机网络证明她年满18岁
接着，预言机网络会生成一份报告，表示Alice已经年满18岁
接着，预言机网络会生成一份报告，表示Alice已经年满18岁
这份可信报告可以作为Alice贷款或其他类似目的的身份认证
这份可信报告可以作为Alice贷款或其他类似目的的身份认证
这份可信报告可以作为Alice贷款或其他类似目的的身份认证
同样地，我们也可以实现保密性
Alice使用零知识证明就可以向预言机节点隐藏她的出生日期等信息

English: 
we can completely conceal the
existence of the gold bars,
conceal all the critical shipping details.
Example two involves
what's often referred to as
decentralized identity.
Suppose that Alice wants to
take out a loan from a bank
and needs a credential proving
that she's over 18 years of
age, a requirement to do this.
She can generate such a proof using DECO.
What she does is log into a few websites
with an authoritative
record of her birth date
and she uses DECO then to
prove to the oracle network
that she's over 18 years of age.
The Oracle network then generates a report
saying Alice is over 18.
This trustworthy report
can be used as a credential
for Alice to take out her loan
or for any other similar purpose.
And again, we get confidentiality here.
Using zero knowledge proofs

English: 
means that Alice doesn't have to reveal
to the oracle nodes, her exact birthdate.
She just proves to them that she's over 18
and that's all they wanted.
We can use exactly this approach
to generate decentralized credentials
from any authoritative website.
Again, with no modification
of the website.
And this seems like a really good way
to bootstrap a decentralized
identity ecosystem.
Our final example involves
confidential DeFi.
Suppose that Alice and Bob wants
to execute a binary option.
What do I mean by this?
I mean, they wanna make a bet
on the value of some asset X.
If X rises, then Bob
pays Alice say 100 ETH.
If X falls or stays the same,
Alice pays 100 ETH to Bob.
This is pretty easy to
do using a smart contract

Chinese: 
Alice使用零知识证明就可以向预言机节点隐藏她的出生日期等信息
Alice使用零知识证明就可以向预言机节点隐藏她的出生日期等信息
她只需要向预言机证明她超过18岁即可
只要证明这一点就够了
我们可以用这个方法从任何权威网站生成去中心化的身份认证
我们可以用这个方法从任何权威网站生成去中心化的身份认证
我们可以用这个方法从任何权威网站生成去中心化的身份认证
同时不对网站做任何改变
这应该是一个创建去中心化身份认证生态的好方法
这应该是一个创建去中心化身份认证生态的好方法
最后一个案例是保密DeFi
假设Alice和Bob希望进行对赌
这是什么意思呢？
就是说他们想要赌资产X的价值涨跌
如果X涨了，Bob就付给Alice100个以太币
如果X跌了或价格不变，Alice就付给Bob100个以太币
这用智能合约和预言机网络很容易做到

Chinese: 
这用智能合约和预言机网络很容易做到
Alice和Bob两个人分别向智能合约存入100个以太币
Alice和Bob两个人分别向智能合约存入100个以太币
预言机网络会查看资产价值
预言机网络会查看资产价值
并将数据传输至智能合约，赢家收到付款
这个机制相对比较简单
如果Alice和Bob都不想让预言机知道他们对赌的内容和对象
如果Alice和Bob都不想让预言机知道他们对赌的内容和对象
那么他可以这么做
他们可以在智能合约条款中添加表示成符号X的隐藏加密信息
他们可以在智能合约条款中添加表示成符号X的隐藏加密信息
他们可以在智能合约条款中添加表示成符号X的隐藏加密信息
合约条款就是决定最终赢家的条款
这里是Bob最终赢了赌局
他可以联系一个可信网站或多个网站

English: 
and the help of an oracle network.
The two players here, Alice and Bob,
each deposit a 100 ETH
into the smart contract.
And then the oracle network
checks the value of the critical asset,
relays it to the contract
and a winner gets paid.
This is relatively simple.
But what if Alice and Bob
don't want the oracle network
to learn what exits, what
asset they're betting on.
What they can do is the following,
They store in the smart
contract a commitment,
a cryptographically concealed
representation of X,
along with the contract terms.
In other words, the terms that
determine who wins the bet.
And then the winner of
the bet, Bob in this case,
can contact a trustworthy
website or multiple websites

English: 
and use DECO to prove
to the oracle network
that he gets the money.
The critical feature we
get from use of DECO here,
is that the Oracle
network doesn't learn X.
And we can also conceal
the terms of the contract.
Before I wrap up, I want
to emphasize to be clear,
that there's one thing that DECO can't do.
A user can't log into a
website, and then unilaterally,
to say on her own generate
a trustworthy DECO proof
that she can then put directly on chain.
DECO cannot generate
such a proof directly.
You need to have the
oracle network and bloop.
(slow music)

Chinese: 
并使用DECO向预言机网络证明他赢了赌局
并使用DECO向预言机网络证明他赢了赌局
这个案例中DECO发挥的作用是
预言机网络无法查看X的内容
另外我们还可以隐藏合约条款
最后我还想要强调一点
DECO无法做到一件事
那就是用户不能在网站上自己生成可信DECO证明并直接发送到链上
那就是用户不能在网站上自己生成可信DECO证明并直接发送到链上
那就是用户不能在网站上自己生成可信DECO证明并直接发送到链上
DECO无法这样直接生成证明
用户必须要通过预言机网络才可以完成
 
