Web3 Summit — Day 1

This is an excerpt of some talks that we found notable at day 1 of Web3Summit 2018. Stay tuned for further updates!

A Query Layer for Dapps

Dmitry Kurinskiy (Fluence)

Fluence network aims to combine the processing of transactions in real-time with the security of a blockchain that ensures validity of each transaction. To achieve that, the network uses local clusters that process transactions on specific datasets in real-time. All nodes nodes in that cluster run a consensus protocol to check in a decentralised way whether a transactions is valid. At some point these nodes bundle all transactions that they consider valid and publish them to a public blockchain which will process these transactions in batch and ensures finality.

DHT, BFT, OMG: Know Your Building Blocks for Decentralised Applications

Kirill Pimenov (Parity Technologies)

Traditional applications usually lead to an concentration of power and single points of failure. There are a some well-working techniques to create decentralized applications (dapps) but the required knowledge is scarce. Relevant technologies are DHTs and gossip protocols that were previously used for filesharing networks like BitTorrent and p2p-networks like eMule. Since the times of early file sharing protocols, there has been a lot of research that lead to more secure versions of these protocols like DHT protocol S/Kadmilia and the gossip protocol BRAHMS. The main advantage of these protocols is that they get along with incorrect, or even malicious, behaviour of a minority of the participants. Newer research led to e.g. conflict-free replicated data types (CRDTs) and for more advanced techniques like practically applicable zero-knowledge proofs that open the doors to even new applications. The questions that arises is how combine that technology to create trustless versions of already existing software, or create solutions for new use cases like trustless decentralised social networks.

Decentralized Oracles: Providing Access to Key Off-chain Data Sources

Sergey Nazarov (ChainLink)

Current blockchains have the problem that they are unable to access data that lies outside of that chain since their state transition algorithms are unable to retrieve data from that resources. And even if they were, there is usually no possibility for them to trigger actions of remote resources. For example, current blockchains are unable to trigger transaction that transfers money from one address to another address just when money arrives on some bank account and send a HTTP request to switch on a smart lamp when the transaction became final. To mitigate that issue, current decentralised applications make use of so-called oracles that retrieve the desired data and call the corresponding smart contract. Since the existence of these oracles contradicts heavily the trustless paradigm of public blockchains, they need to come along with some meaningful argument why people should trust them.

A solution might be the usage of a decentral network that runs a classical consensus mechanism and reaches eventually a consensus on the retrieved data. Running such a network is expensive since most likely none of the nodes will provide this service without a compensation, so this mechanism seems to work only for high-value transactions.

Another idea is to use trusted execution environments (TEEs) like Intel SGX or ARM TrustZone as a security anchor. The advantage of these TEEs is that they are able to compute nearly any functionality that is efficiently computable on normal processors. Since the operator of the computing resource has no ability to manipulate the computation process — except from turning off that machine — they do not need any replication and consensus protocols to ensure correctness of that computation. As TEEs usually come with a built-in random number generator, they can also serve as source of entropy that is queried whenever a smart contract needs randomness.

However, although TEEs make a lot of things easier, it is good to remember that they are only secure as long as the embedded signing key is kept secret.