What is Web3.0? That is a good place to start. Web3.0 is distributed infrastructure lacking trusted authorities. Another way of thinking about the lack of trusted authorities is to always assume a minority of the nodes in your system are bad or corrupted. Web3.0 systems are resilient and tolerant to these bad nodes.

Use Case Web2.0 Infrastructure Web3.0 Infrastructure
Banking: Transfer of Funds Bank acts as authority backing funds and ensuring transfer Bitcoin enables direct fund transfer
Software: Continuous Integration Only central deployment agent has authority to push software to services Anyone can deploy if they hold the required verifiable credentials
Communication: Video Call Routed through central exchange Peer to peer, for best connections additional intermediary peers help in exchange for fees or network credits
Events: Tickets Big company creates end-to-end ecosystem. The Big Company generates, stores, and validates tickets Tickets are stored on mobile phone, seat owners create tickets, venue authenticates ownership

In each of these cases Blockchain is a crucial technology but it isn't enough. Blockchain is used as a centralized store, where the state and contents of records are agreed on through a consensus mechanism. Examples of a consensus mechanism is the proof of work algorithm in Bitcoin, or the proof of stake validation in Cardano. The Blockchain acts like a centralized ledger making sure everything is properly accounted.

Use Case Blockchain Usage
Banking: Transfer of Funds Accounts for every token and transfer, no double spend, no missing money
Software: Continuous Integration Accounts for every certificate in the system, and public key for verification
Communication: Video Call Accounts for every node in the network and public meta data like node-type, node-availability
Events: Tickets Accounts for every seat, and public keys for seat owners and venue

This article covers the Web3.0 infrastructure needed into addition to BlockChains.

  • Off Chain Storage
  • Private Key Management
  • Distributed Key Management
  • Distributed Ids
  • Distributed Message Passing

Off Chain Storage

Storage for Private Keys, Personal Information, and Need to Know Data

Blockchain data is publicly available for everyone to see. That means private keys, personal information, and need to know data can not be stored on the blockchain.

It is obviously a bad idea to store private encryption keys on a public storage solution.

💡
Off Chain Storage is needed to secure Private & Personal data. Blockchains are not a good place to store Private & Personal data.

Encrypting personal information and storing it on a Blockchain is not a good idea. Owners lose control of their personal information if they stored it on a Blockchain. Remember Blockchains are an append only storage solution. Once a record is written to the Blockchain it is modified by writing a new version of that record. Therefore, in addition to current state, Blockchains stores past transactions and previous states available for all to see. So a user would be unable to delete or re-encrypt their personal data because the old versions would always be around. For example if I encrypted my credit card on a Blockchain. That encrypted secrete may have a zero-day flaw and be exposed later. If I want to update my credit card number I can update to the new number, but I can't remove the older number. Finally if my private key is lost I would assume my encryption is compromised and the credit card associated with the number needs to be deactivated.

Ideally there would be another, off chain, storage system with the following properties

  • Cryptographically secure storage
  • Access Limited to Private Key Holders

Private Key Management

Managing Secrets in a Distributed Untrusted Environment 

When you need to encrypt personal data or sign a certificate you'll need to use your private key. Your private key is the gateway to your identify and your personal information. Web3.0 assumes bad and corrupted nodes, so folks typically store their private keys in one or more of the following places

  • Smart Wallets on their mobile devices
  • USB storage devices stored in a safe place
  • Recovery Seeds written down on paper
💡
Private Key Management functionality is a must. You can not lose your private key.

There are plenty of stories of Bitcoin millionaires digging through trash looking for old hard drives with their private keys.  Without the private key these millionaires can't access their funds. Same is true for personal information. Therefore if your device with your private key is lost or stolen, the recovery seed will help you recovery your private key; however you will need to manually migrate your personal data a new encryption, update all of your public keys, and update all your private keys.

Private Key Management requires the following:

  • Recovery mechanism for lost keys
  • Nice User Interface to limit human error
  • Ability to rotate or swap in new private keys
  • Verifiable Credentials
  • Distributed Message Passing

Distributed Key Management

Generating, Sharing, and Decommissioning Public Private Keys 

Managing Public/Private key pairs is not easy in a distributed world with no trusted authority.

💡
New Infrastructure is required for managing Public/Private lifecycle when there is no central authority.

In a Web3.0 world a Distributed Key Management system is needed to support the following functionality while being asynchronous, secure, and verifiable:

  • Generate Public / Private Keys pairs
  • Provide a way to recover secrete even when a key is lost or compromised
  • Provide a way to rotate in new keys
  • Provide a way to delete or remove keys

Web3.0 Generation of Public/Private key pairs is covered under the topic of Asynchronous verifiable secret sharing (AVSS). AVSS alone does not provide the ability to recover, rotate, or remove keys. That requires additional functionality, and is typically managed by an Application Supported by Off Chain Storage solution. The Application may be supported by a network of asynchronous nodes, or it may be supported by a smart wallet capable of multi-sig.

Distributed Ids (DID)

Ownership of Personal Data

Records on the Blockchain are needed to link personal data to applications that can provide that data. Remember personal data is stored off chain, so something needs to index and point to that data. Distributed Ids (DID) does just that.

💡
The Decentralized Identifiers (DIDs) defined in this specification are a new type of globally unique identifier. They are designed to enable individuals and organizations to generate their own identifiers using systems they trust. These new identifiers enable entities to prove control over them by authenticating using cryptographic proofs such as digital signatures. W3C DID v1

DID need the following properties. The W3C DID v1 spec has a long list of qualities, but for me the following are the four definitive properties. Additionally the Anonymity via Ephemeral Ids isn't an official part of the spec, but more DID providers do it and it seems like a great idea.

  • Anonymity via Ephemeral Ids - they are just ids, and you can generate new ones on the fly targeted for a specific data exchange
  • Decentralized - no central authority exists
  • Verifiable - use cryptographic proofs to verify legitimacy, and Blockchain to make sure only one true copy exists
  • Public - everyone can see and access the links

Verifiable Credentials

Tamper proof and private 

Verifiable Credentials are needed to exchange data, goods, and services. A Verifiable Credential could be ticket to a hockey games signed by the seat owner and the venue, or it could be a license for payroll service to access a list of employees and this week's pay.

💡
A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. W3C Verifiable Credentials

We need new software systems that manage the lifecycle of these Verifiable Credentials. Two new pieces of infrastructure are needed. We need software to generate the credentials, and software to hold and display the credentials.

Infrastructure to create and track credentials

  • Generate credentials matching the proposed schema
  • Attach the proof from the trusted authority
  • Log and keep track of credentials issues and their lifecycle properties (e.g. expiration date)

Infrastructure to store and manage credentials. The W3C spec has a concept of presentations, where a holder can show some data in the credential, and even join multiple credentials together to make a more meaningful claim.

  • Application to store and track credentials access
  • Application to join, and project credentials (e.g. limit what is show combine multiple credentials into one statement)

Distributed Message Passing

Distributed Communication 

Smart contracts can only work on data on the Blockchain, or data passed into the contract's constructor. This is done to keep the Blockchain free of unreliable external dependancies that might prevent contracts from running to completion, and hogging resources. As a result the state of a contract is stored on the BlockChain where the Smart Contract resides. This is limiting, and it requires a reliable, centralized service to manage the state machine when the Smart Contract is broken into multiple pieces, or the Smart Contact spans different BlockChains.

💡
New Infrastructure is needed to pass messages between asynchronous networks so Web3.0 systems can talk to each other. 

A Distributed Message Passing Services would need to have the following properties

  • Asynchronous
  • Eventually Ordered, resilient to late arriving messages
  • Resilient Bad or Corrupted Nodes