Frictionless DAPPS

● Part I is an overview of important terms and some background.

● Part II discusses the background of how frictionless Dapps work

‍

Part I. Intro

Frictionless logins by a distributed private key management solution. Through removing the hassle of managing private keys, this process takes a significant step forward for mainstream adoption. How this process works is through a distributed key generation scheme allowing users to use DApps by linking their current existing social user accounts (i.e., Google) to public-private key pairs. By tying oAuth logins to keys, this process creates a cross-platform identifier making it easy for users to use their social credentials anywhere on a decentralized web.

Concepts

It is essential to know these basic concepts and tools:

‍

DApp

A decentralized app or DApp is an instance of a program which accesses a blockchain through a node of the Blockchain, and then sends a request on that specific node’s copy of the Blockchain. This process is to transfer cryptocurrency usually or to call smart contract functions. After the request places, it gets propagated and written on other nodes copies of the Blockchain. As opposed to a centralized app that runs on a single computer, DApps run on a P2P network of computers. The core logic of a Dapp application is a smart contract. Smart contracts play an integral role in the building blocks of blockchains as they process information from external sensors or events that help the Blockchain manages the state of all network actors. DApps are similar to a regular web app. The frontend uses the same tech to render the page. DApp’s contain a “wallet” that communicates with the Blockchain. The “wallet” manages the blockchain address and the cryptographic keys. Moreover, Public-key infrastructure confirms user identification and authentication. Without a “wallet” that manages our digital identity, users would not be able to interact with the Blockchain.

‍

Web3

Often Web3 is referred to as the next generation of WWW. Ethereum ecosystem has adopted Web3 and co-opted to refer to a decentralized web. Web3 is Web2 without the centralized servers and data silos. Specifically, it changes the data structure on the backend of the net, introduces a universal state layer, and then incentivizes by network actors with a token.

‍

Web3.js

Web3.js is a library that allows developers to interact with the Ethereum blockchain. Javascript language represents a binding for Ethereum’s JSON RPC interface. Web technology is then usable as Javascript is supported natively in most web browsers. Moreover, Web3.js is a popular tool for developers on the server-side in Node.js applications. Web3.js can be used to connect to the Ethereum network by any Ethereum node that allows access via HTTP. Such as a local node, a node hosted by the DApp provider, or public gateways.

‍

Ethers.js

In short, ethers.js is an all-purpose alternative to web3, the most commonly used library for Ethereum applications. For developers who have built DApps on Ethereum, you most likely used Web3.js to develop your Javascript frontend. In comparison to Web3.js, Ether.js is a lightweight Javascript library that can be used as an alternative to develop your Javascript frontend and interact with the Blockchain. Ultimately, the Ether.js library aims to be a complete and compact library for interacting with the Ethereum Blockchain and its ecosystem.

‍

Public Key Management (PKI)

Blockchain apps rely on cryptography as a method of certifying transactions are done safely, while at the same time securing all information that is stored. It accomplishes this by obtaining the identity of the sender of transactions and making sure records cannot be tampered with. Consequently, any user on a blockchain can have absolute confidence that once something records, it is legitimate and has been conducted through a method that maintains security. How Blockchain accomplishes this step is by leveraging a trust model that attempts to prove the identity of the user (authentication) and verify permissions (authorization). Moreover, this service is deployed on-demand, easily scales as blockchain platforms or applications grow, and used where needed to optimize blockchain transactions. Private key cryptography provides the user with a powerful ownership tool that manages the authentic requirement by developing a secure digital identity reference. Identity is based on the position of a mix of private and public cryptographic keys.

‍

Public and Private Keys

Every user on a blockchain has to have a public and private key. Blockchain uses public cryptography through public and private keys to execute transactions and public cryptography. Private and Public keys are a series of very long number sequences that are unique to an individual user. Usually, Private and Public keys generate a private key after a user creates a “wallet.” Private and Public keys are 256-bit long key, which makes it highly secure. The Public Key is precisely what its name states, a key a person shares with the blockchain network.In contrast, the private key is meant to be kept secret as it confirms an individual’s identity in a transaction in the Blockchain. The two keys combined develop a digital signature that is crucial in opening access to a transaction or a piece of information. The combination of the user’s Private and Public keys generates a digital signature, which confirms that the user and the user only- have executed the desired transaction.

“Trustless”

Contrary to popular belief, Blockchains do not eliminate trust. What Blockchain does is minimize the amount of trust required from any single actor in the system. When a developer uses the term “trustless” for Blockchain, what they mean is that there are specific mechanisms in place by which all parties involved in the Blockchain system can reach a consensus on the canonical truth. Trust distributes among the network’s stakeholders rather than centralized in a single entity or particular individual.

‍

Nodes

Blockchain exists on a block of data. These blocks of data stores on nodes. Nodes are the infrastructure of Blockchain. The nodes on a blockchain are connected, and they continuously exchange the latest data to stay updated. Nodes store spread and preserve data on the Blockchain.When a miner attempt tries to add a new block of transactions to the Blockchain, it broadcasts the block to all of the nodes on the network. Depending on the block’s validity of signature and transactions, nodes either accept or reject the block. When the node accepts a new block of transactions, it saves the block on top of the rest of the blocks.Nodes can work on and offline. Online nodes are receiving, storing, and broadcasting all the latest blocks of transactions on the Blockchain to and from other nodes, while offline nodes do not. When an offline node comes back online, it synchronizes with the Blockchain by downloading all blocks that were added ever since the node went offline.

Smart Contracts

Smart contracts are deployed on a public blockchain network and are self-executing and immutable after their signing. The use of Smart Contracts is limitless as they can be used to develop decentralized exchanges, tokenizes assets, transactions, contracts, games, and more. A smart contract is a persistent bit of software that embodies a secure encrypted transaction between multiple parties, so anything in a smart contract can be scripted and automated securely. Apart from the customizability and the digital signatures attached, smart contracts are smart because of this self-executing nature. In the legal world, when a contract is signed, the parties are accountable for fulfilling the terms of the agreement on their own. A self-executing smart contract, in this sense, requires no effort: when you sign a smart contract for the transfer of funds, the funds transfer themselves across the Ethereum network and record the transaction on Blockchain as immutable public data.

‍

Sharding

Sharding is a popular method being explored by developers to increase transactional throughput. Sharding is a way to partition spreading out the computational and storage workload across a P2P network so that each node is not responsible for processing the entire network’s transactional load. Instead, each node maintains only the information related to its partition or shard. Sharding can still proportion the information contained among other nodes. This way, it keeps the ledger decentralized and secure because a user can still see all the ledger entries; they just don’t process and store all the information.

‍

Distributed Key Generation

A cryptographic process where multiple parties contribute to the calculation of a shared public and private key set. Contrary to Public Key Encryption, DKG does not depend on trusted third parties. A threshold of participating honest parties decides if a key pair can be computed successfully. This involvement ensures secrecy in the presence of rogue contributions to the key calculation.

‍

Byzantine Fault Tolerant (BFT)

Byzantine fault tolerance (BFT) is the property of a system that can resist the class of failures derived from the Byzantine Generals’ Problem. This means that a BFT system is able to continue operating regardless if some of the nodes fail or act maliciously.

Tendermint

Tendermint is a minor protocol comprising of two pieces: a Blockchain consensus engine and a generic application interface. The Blockchain consensus engine, or rather the Tendermint Core, aids the peer-to-peer network and issues a proof-of-stake(PoS) consensus. The design and purpose of Tendermint are to be a Blockchain engine.

Application Blockchain Interface (ABCI)

ABCI is an interface that defines the boundary between the replication engine (the Blockchain), and the state machine (the application). Using a socket protocol, a consensus engine running in one process can manage an application state running in another.

‍

Part II: How Frictionless Works

By developing a frictionless login, this process helps drive adoption and conversion rates for your DApp experience. This simple and secure gateway makes Blockchain easy to use for as many people as possible. While any user can read the information on the Blockchain – to write on Blockchain, you would need to own a private key. As described above, a private key is a secret that generates randomly when you create a wallet. The nature of a decentralized Blockchain means that every user needs to safeguard their private key. Otherwise, there is no way to recover it. If someone maliciously gets their hands on a copy of your private key, there is no turning back the wheel. For a non-developer or a non-crypto user, this may sound harder than it sounds. When using Google, for example, the user did not have to control their data. That service or other services for that matter did that for the user, which is why they really never had to own a private key truly. Nevertheless, users expect familiar and straightforward ways to onboard and use DApps. Luckily this process redefined this experience, whether the user knows Blockchain or not. As a developer, using DApps should be seamless, as should be developing them. All it takes are a few lines of code to start using this process today. Now that we have covered some essential concepts, let’s dive deeper into the functionality under the hood.

Splitting the user’s private key into shards is how frictionless logins function. The process of sharding starts with a database partitioning that involves breaking up large databases into smaller, more manageable segments. The idea of sharding stems from the idea of improving performance and reducing the query response time. When sharding is applied to Blockchain, this means it breaks up the blockchain network into individual shards. Each shard holds a unique set of smart contracts and account balances. Next, nodes are assigned to individual shards to verify transactions and operations. This process is contrary to being responsible for verifying every single transaction on the entire network. By breaking up the Blockchain into more manageable segments, it leads to increased throughput of transactions and therefore, overcoming the scalability issue facing the growth of a decentralized ecosystem globally. On this basis, this process has innovatively developed a solution that applies Distributed Key Generation (DKG), an encryption process in which multiple parties involved contribute to the calculation of a shared private and public key set. Alternatively, Distributed Key Generation, unlike Public Key Encryption models, do not depend on third parties. A threshold of participating equitable parties determines whether a key pair can be computed successfully or not. Distributed Key Generation averts single parties from having access to a private key.

How the system splits up the user’s key into multiple key shards is by distributing them throughout a network of five nodes run by ecosystem stakeholders, which include but are not limited to; Kyber, ETC cooperative, Binance, and Terminal. To forgather the private key,out of nine nodes, five nodes need to share their respective key shards. By having private key shards distributed among these nodes, it makes maintaining them more accessible. A distinct factor of this solution is that nodes generate a private key collectively without ever actually putting the key together in a centralized location. Through this process, this process minimizes trust assumptions, works across all devices and browsers, and allows for built-in account recovery.

‍

Let us dig a little deeper.

‍

Aforementioned, smart contracts manage nodes for a fixed period in which they generate a set of keys through Distribution Key Management. Nodes in charge of the Distribution Key Management in this process start with primarily running the key generation protocol, which then maps the key, and thereupon re-shares its key to the abutting set of nodes. These nodes consist of an epoch of nodes that run as a network together. Every epoch individually has a set of nodes that are in charge of the node operations. When the nodes have completed their task, they migrate the necessary state over to the succeeding epoch’s nodes. This system does not centralize any state other than the mappings of certain IDs to verify IDs and private keys. Instead, the only systems required are the ones that migrate mappings and private keys across epochs. Correspondingly, this network of nodes can store private keys and connect them to the matching user ID and permit users to retrieve them through non-cryptographic authentication methods. The network has no other shared state besides the continued mapping of keys to user ID’s. This process consists of applying Tendermint to have a Byzantine Fault Tolerant (BFT) replicate the state to share this mapping state between nodes. The entirety of the highly performant Tendermint consists of two chief technical components: a Blockchain consensus engine and a generic application interface.

‍

The Tendermint Core, or rather put, the consensus engine, ensures that the same transactions record on every machine in the same order. The application interface or the Application Blockchain Interface, on the other hand, allows a transaction to process in any programming language. Unlike some other Blockchain and consensus solutions that come prepackaged with built-in state machines, developers can use Tendermint for BFT state machine replication of
applications written in any programming language and environment that is right for them. Nevertheless, this node is not a typical distributed system since each node operator only runs a single node.​

‍

Verifying secret sharing is a vital basis in distributed cryptography. This process operates on the assumption of the honest majority that seeks to shield itself from some byzantine adversaries, such as the prevention of reading or modifying messages or controlling the networking and delaying messages between any two honest parties. Consequently, this is why the asynchronous model replaces the traditional assumption of a synchronous network here. For the deployed scheme, this process runs Distributed Key Generation via a cryptographic scheme using asynchronous verifiable secret sharing that supports a dual-threshold sharing. Specifically, a 3/4 honest majority with a 1/2 + 1 reconstruction threshold.

‍

Everything comes down to making Private Key Generation and communication secure. What protects these communications from being ‘heard’ by anyone is private keys. The key generation requires several rounds of communication. Therefore, it is imprudent to carry this step out whenever a user needs new keys. What this process has done instead is develop buffers of unutilized keys beforehand, so that it would only need to assign them to users when they request for new keys. Furthermore, it is again for this reason why this process applies Distributed Key Generation as this method simplifies matters considerably, reducing the rounds of communication, but at the expense of message complexity and some initial logical overhead.

‍

This scheme generates a random 2d plane and builds horizontal and vertical slices at the appropriate indices as sharings. Specifically, vertical scaling entails the expansion of a network by adding more power and memory to a system’s core processing unit, whereas horizontal scaling involves the addition of more nodes to the framework of an existing system. This process acquires sub-sharings on these horizontal and vertical sharings at the appropriate indices, and echos them to other nodes. At the time that sub-sharing receives other nodes, as a node, it should equal the inceptive sharing that the node collects, and if they do not, the node can always interpolate the correct sharing via these echos subsharings. Here the dealer complaint phase is removed, and thus this process restricts itself to just the horizontal domain such that the final sharings are still on that of a univariate polynomial. The closing process formulates the respective private key since the nodes derive from an aggregated share to a master public key pair.

‍

‍

The backend of frictionless logins further consists of having keys assigned to a combination of verifier and verifier_id. This assignment triggers by any node and resolves through the nodes consensus layer. The consensus layer provides a protocol that describes the format of a ledger that is publicly visible and a consensus function that anyone can use to determine which of multiple candidate ledgers is the consensus ledger. The protocol must also allow for adding new blocks to the ledger. Instead of only allowing the OAuth framework to utilize, this process allows for general identifiers to be implemented by the external verifier through at least two API’s. Specifically, the first API that issues unique tokens with a unique representation and secondly,

‍

‍
an API that consumes these tokens and returns user information and the issued token. Typically any entity that fulfills an interface and provides signatures on unique ID strings and timestamps can be a verifier. This process is extendable to most authentication schemes, including many implementations of the OAuth standard and OpenID Connect.​To prevent rogue nodes, this process applies Front-Running Protection from malicious nodes that act as a legitimate node. These rogue nodes hail from Front-running vulnerability when the order of transactions has been unfairly changed to benefit one party and where the transactions in question may end up in the same block. These rogue nodes can steal, modify, or create wrong data.

‍

To prevent this issue from taking place, this process uses a commitment scheme on its token to warrant that all nodes are confident that most other nodes are aware of the commitment before being revealed. A private key generates so that nodes encrypt incoming communication and then further hashing the received token from the first API. A signature is then asked for on the hashed token from all participating nodes where they then bundle these signatures altogether as verification. Through this step, the proof is gathered and submitted with the plain un-hashed token to each node to get back the shares. By encrypting the share with the associated temporary private key, there is no way for a rogue node to acquire this proof by intercepting the original commitment to which may contain a revealed token with proof. Honest nodes never give out shares for a token whose commitment has been seen before. The idea is to give out nodes but to be sure that the final incoming request with proof is not a front runner.

‍

Ultimately, node migration through Proactive Secret Sharing updates keys in a secret sharing scheme frequently such that rogue elements have less time to compromise shares. As long as this step is taken and the rogue elements have less than a threshold, the system remains secure.

‍