[Music]
thanks.thanks me hi everyone so the the
problem that we're we're focusing on is
one which we think keep smart contracts
limited to tokenization right if the
native functionality you have when you
start working with a smart contract
network is the ability to make tokens
that's the functionality you'll start
working with and you'll do a lot of
interesting things with it but the
capabilities of smart contracts go far
beyond to organization there's enough
logic to mimic and eventually replace
the majority of digital financial
agreements those agreements as they're
structured will need triggering events
so they'll need inputs into the
application and they also need to have
outputs as a form of payment right so in
our opinion one of the very large
limiting factors for the creation of
interesting real-world use case smart
contracts is their ability to step
beyond tokens and interact with external
inputs and external outputs in a
meaningful manner right so the approach
to solving that problem is basically
middleware you create a piece of
middleware that takes the external
inputs turns them into something that
the contract Unchained can interact with
and you have the middleware provide
those inputs to the contract those
inputs can be any kind of data feed IOT
input about delivery any any input that
application needs likewise the
middleware can provide outputs into
relevant payment systems now right now
there isn't a large amount of these
capabilities and the parallel I tread
tend to draw in my mind is in the web
development world when you want to build
an application you have a ton of api's
you can connect to a contract right in
the smart contract development world
right now due to the lack of unchained
contracts that represent off chain
resources it's very difficult for a
smart contract developer to get access
to the inputs and
the outputs they need to make an
application right like the people that
made Ober or any number of other web
applications they put the GPS API any
number of other api's together with
their core application and then they had
a payments output in a payments API
right it should be just that easy for a
smart contract developer to take inputs
combine them with their core application
in the form of a smart contract and then
have that smart contract to make the
relevant outputs without them figuring
out how to make that connectivity work
at a very deep level right that's that's
what blockchain middleware as a general
solution provides right the the benefit
of a blockchain middleware for a smart
contract ideally would be that it
maintains the same level of security as
the contract right you don't want a
contract that's highly secure that's
triggered by a highly insecure system
and that pays out through another highly
insecure system if you have a very
secure middle part of the end-to-end
setup and the inputs and the outputs are
insecure it's unlikely that digital
financial agreements of large value are
going to transfer from the legacy world
into the smart contract world right so
as a community or at least we as a group
of people are very interested in solving
this problem of how do you get a smart
contract to do something meaningful
relative to the real world but also to
do it so securely that the input of the
data that triggers their contract the
contract itself and the output can all
be trusted at a very high level of
tamper-proof enos so to understand what
our options are in this problem it's
good to look at like what is some of the
current approaches one very common
approach is basically the use of a
centralized Oracle so that is the
approach where either an individual in
the contract runs an Oracle one of the
counterparties or possibly a service in
any case there's a single centralized
Oracle that acquires data as a trusted
third party and gives that data to the
decentralized computation Network to
process it right
the problem with this in our opinion is
that the decentralized computation
network has thousands of nodes which
provide the tamper proof nests and the
security guarantees we all value in that
contract while the centralized Oracle
shrivelling triggering this highly
tamper proof decentralized computation
is not tamper proof right so the set up
end-to-end at this point is not tamper
proof it's not going to appear very
secure it doesn't provide the tamper
proof guarantees that that we think are
important for smart contracts to have a
unique value right and so this attack
vector of how do you attack a contract
that has one node triggering the key
events is is the attack vector that we
think is worth worth seriously
considering everything from DevOps
problems with that one node to somebody
genuinely attacking a single node to
stop a contract from running on you know
could be a million nodes it doesn't
matter how many nodes are in the
decentralized computation environment if
the trigger is attacked and compromised
and doesn't happen the contract won't
trigger so the the approach that we
advocated this problem is twofold the
first part of it is decentralization so
we apply the idea of decentralization to
Oracle's to blockchain but aware and we
create an Oracle network that is able to
process and acquire the data using
multiple independent node operators
those independent node operators can be
selected by the person making the
contract and they can select as many
note operators as they want to five 10
50 100 however much decentralization
they want at this level of middleware
they can now acquire to give them
guarantees about tamper proof venus in
terms of their inputs this ability to
decentralize the blockchain middleware
layer the Oracle layer also gives you
the ability to now contract with
multiple data sources in our opinion it
doesn't make as much sense for one node
to use five data sources you centralize
the data at the level of the origin but
it's still going through one point of
failure now once you have for example
five separate decentral
doricles they can all acquire data from
five separate data sources if that's
something that your use case needs so
it's there's gonna be an entire spectrum
of use cases that doing don't need this
but in our opinion the high-value use
cases are going to want to provide a
high level of tamper-proof eNOS through
the centralization right which is which
is what we we'd like to enable so that
the end-to-end setup is sufficiently
secure for people to trust it to put
actual money into a smart contract for
things to go to production the the other
part of our approach is that it's open
source and we believe very strongly in
open source and security reviews through
open source both on the level of the
Unchained contracts and the off chain
implementation of the middleware and we
believe that a shared large community of
people working towards the blockchain
middleware that can solve this problem
will make a blockchain were aware that
payments processors data providers these
signature providers various API services
will adopt because they don't want to
build their own middleware they just
want to sell their services and they
constantly buy things that just let them
sell their services so what we should do
in our opinion is that if we as a
community are interested in this problem
we should solve it in the decentralized
manner that allows the people with the
data resources payment resources each
signature resources various other api's
to be able to provide those services to
contracts so those contracts can then do
something much more meaningful right now
the second part of our approach after
the centralization and open source is
the application of trusted hardware so
trusted Hardware provides certain tamper
proof nice guarantees in this case
applied to Oracle's those guarantees
extend as far as the note operator will
not know what they are running the note
operator will not be able to tamper with
the data the note operator will really
only be able to turn off their node and
that will be an immediate signal and
with even basic reputation systems they
won't participate in future inputs into
high-value contracts right so the
application of trusted hardware and its
new recently fall form in terms of Intel
SGX is something we think has a lot of
merit and and is an approach that that
can create a decentralized oracle
network where you can sufficiently trust
the independent node operators to
execute the acquisition of data and the
act and the execution of payments while
not knowing important things like your
payment credentials or what data they're
executing another very large benefit is
the ability for you to do all chin
computation in this same Oracle network
so the Oracle network can now become a
desire of all the same computation of
around the data it acquired for
intensive computations that you can't or
don't want to do unchanged so to dive a
little deeper into trusted Hardware and
and why we think it's an interesting
approach the the the main premise
underlying trusted hardware is that
compared to previous approaches like
various HSMs various data rights
management modules it has a smaller
trusted computing base so what that
means is that privileged system code
like the OS and BIOS are no longer
attack vectors for something like an
Intel SGX Enclave what that means is
that you can give even encrypted code
into the the Enclave and it can decrypt
it and run and make outputs and the
operator of the node running something
like until SGX
can't tell what's going on they they
can't acquire private information and
once again all they can really do is
turn it off which becomes a me
immediately apparent now the the
approach that that we're adopting
towards trusted hardware in the context
of a decentralized oracle network with
the help of the very smart folks at ic3
who were very lucky to be working with
our is called town crier town crier
basically applies Intel SGX which at
this moment appears to be the leading
trusted Hardware approach
to the problem of secure tamper-proof
Oracle's it basically allows a contract
to talk to an INT SGX enclave that then
using the existing TLS scheme can
acquire data from a data source and then
provably return only the value that it
acquired from the Enclave into the
requesting contract right in this case
the requesting contract is the
town-crier contract which then kind of
is the unchained bridge from the Enclave
into the user contract right so it's
it's a very common Oracle set up but the
the difference is that the Enclave
provides this tamper proof guarantee
right so in our opinion when you look at
how do we make smart contracts useful
what is their unique value it's the fact
that their tamper proof tamper resistant
kind of these unstoppable financial
agreements and as as tamper proof as we
can make something like the triggers of
those agreements is probably the right
direction to go in and and those two
approaches once again
one is decentralization and the other
one is the application of trusted
hardware now how this would look if
trusted Hardware works and everything
works out properly is that a user shows
up and says I have a very large
computation that needs data I'm going to
give that computation into the the
relevant node the relevant node is going
to take that computation and run it in
the Enclave inside an EVM right so
there'll be an EVM running inside the
Enclave the EVM will run the computation
and it will run it privately such that
even the node operator can't acquire the
data if and then they'll return a query
ID the query ID is what's used to pay
the contract and it returns relevant
information for payment after that well
what happens is let's say one of the
counterparties wants to know what is
this Oracle doing what is this
decentralized oracle network or this set
of Oracle's that is that are going to
trigger the agreement that I'm a part of
what actions are they actually going to
take can you
please return to me the code that you're
gonna execute at Timex at that point the
counterparty this case Bob receives back
an encrypted blob which he can decrypt
because he has the relevant private key
so in in this scenario what's been done
is that the creator of a smart contract
has written in Oracle instructions in
this case in solidity so they've written
Oracle instructions in in in a format
they're already used to working with
that that compiles down to EVM byte code
they've put those Oracle instructions
into the V Enclave they've set it up to
trigger their contract without the node
operator knowing they've done this with
anywhere from 5 10 15 20 in the
individual node operators so that if one
fails or if one is attacked it doesn't
it doesn't compromise the execution of
the contract and then they've done it in
such a way that if their counterparty
wants to know what is the Oracle setup
we're using going to do at time X let me
randomly checked at any time I would
like they can go submit the query ID and
receive both the encrypted blob and then
anta station from the Enclave proving to
them that the execution that is supposed
to happen at time X is is going to
happen right so at this point we we have
multiple node operators executing a
valuable off chain operation and we have
them being able to prove it
to the other parties in the transaction
the the benefits of this approach in our
opinion are basically that you can have
very scalable execution off chain you
can put put a well not anything but but
definitely much more much more intensive
computations into SGX and very possibly
things you would never want to be public
of and under certain conditions of
encryption or other things due to the
privacy of SGX
you can basically acquire some amount of
surety that's the node operator that
you've given the code to hasn't hasn't
acquired it and you can also do very
interesting things such as have smart
contract control private keys so how we
think this is going to evolve is that
you're going to write one big one smart
contract in in two parts right you're
gonna have an off chain part both of
them written so that you can have an off
chain part the off chain part is gonna
is gonna make all kinds of all chain
requests that look like this and require
all kinds of computations
you're gonna write it in solidity or
whatever language you'd like that goes
down to the VM bytecode you're going to
run it into and and an SGX Enclave and
then that as G ox Enclave will have
capabilities such as the control of a
private key or the ability for the SGX
Enclave to make a direct request to a
native OS library for something as
useful as randomness right so the the
thinking here is that you you don't
learn a new language for Oracle's or
anything super specific you you continue
writing in the language that you're
writing your contract in but you have an
off chain portion the off chain portion
relates to your acquisition of data and
your computation around that data and
then the on chain portion is what you
have on chain that is presumably
triggered by that on chain data but by
the off chain data that that reaches it
and then presumably you have another
section to the contract where you have
off chain payments where you want the
contract to send some kind of payment
message to a payment network or a bank
or or any other system that has their
own blockchain middleware that
represents their services right and then
also if if you want if you want key
resources such as randomness or any
other number of resources that can be
provided from a native OS library that's
been widely used and tested you can
acquire it by directly messaging within
the Enclave so there's there's entire
subsets of of what you're all chained
computation can have within the Enclave
by having it message something like a
native OS library from randomness
eliminating certain scenarios where you
would ever need to use a service and you
you kind of get the tamper proof
guarantees both
on the level of the data acquisition and
also on the level of this native OS
library once again also very possibly
run in multiple nodes and those nodes
being able to come to the centralized
consensus about about the execution of
of that computation and even the
acquisition of randomness now the the
reason we're we're kind of applying this
level of stringent security and tamper
proof Ness is that the world we'd like
to be in in a year or two years
relatively soon is is the ability for a
contract to reach out to another
contract on chain and for that Unchained
contract to represent an off chain
resource so that a smart contract
developer no longer needs to learn api's
they have an entire list of contracts on
chain which we call chain links but you
know are basically Oracle's that
represent every type of data of chain
payment mechanism is signature basically
any any web service that a web developer
gets access to to build their
application is a service that a smart
contract developer should be able to get
access to from a contract on chain and
and that's the that's the quick
prototyping world we want to be in for
people to build killer applications of
smart contracts by focusing on their
core application and getting all the
inputs and outputs they need while
making sure that those inputs and
outputs are sufficiently secure that
their end-users the other parties in the
agreement trust that the source of the
inputs the method of input the contract
itself the method of the output is is
sufficiently secure to trust that
end-to-end setup right the the world we
want to avoid is one where you have a
highly secure decentralized computation
that is then triggered by highly
insecure services which once looked at
lead people to not put any real value in
the contract right that's the world we
want to get away from and the world of
secure end-to-end smart contracts is the
world
like to approach if you'd like to know
more you can find the technical details
in these two papers and we're always
happy to discuss this and we're also
working on this in an open source manner
and looking for we're interested folks
to join us to solve this problem so
thank you
[Music]