The decentralized internet: A former dream which has become progressively more real with each step in infrastructure development - each more exciting than the last - and yet, still a dream. As natural as obstacles are during innovation, our collective approach has advanced to a stage which is longing for a more precise understanding of these obstacles, analyzed from first principles with enough rigor to extract the most ingrained insights... but without stopping to dream and innovate.
That is the ideological basis behind developing the framework presented in this document, along with a solution for one of the biggest obstacles for making said dream a full reality: Access to your Web3 assets which is both secure and Intuitive.
Leaving buzz words behind, this more precisely means to ensure the permissionless and trustless properties across the asset management pipeline all the way from its blockchain representation to the end user. This makes your assets end-to-end resilient and robust to traditional cyber-attacks, system failures and downtime, while offering intuitive management experience for the user.
In this document we highlight the formulated pipeline, its properties and its origins to present how Security Labs’s authentication framework is inevitable from first principles and all of its use cases help build our dream into fruition: Make decentralized apps actually intuitive and usable.
If you’re specifically looking for:
The main objective to make Web3 usable is to connect two endpoints:
¹ In simple terms, permissionless is the property of a system to welcome anyone to participate in its operations without requiring no condition at all. There are definitely degrees of “permissionlessness”. For example, creating a wallet in Ethereum blockchain requires nothing more than computing a ECDSA key pair and a subsequent Keccak-256 ****hash (which is a really minimum requirement most devices, albeit still some requirement), but participating in its consensus mechanism requires at least 32 ETHs, which is less permissionless in the sense that the set of users allowed by their wealth to participate is smaller.
² When the components/participants of a system have a set of possible intended actions, then any deviations from said actions can have ill results. In absence of mechanisms to mitigate their impact, we are forced to have some set of trust assumptions about these agents. Systems which have few assumptions are referred as trustless, and if we can have zero assumptions (i.e. allow for any behavior deviations), we say the system is zero trust.
This connection has still yet to be established successfully, since fully decentralized assets come with the burden of self-custody (managing some form of private key securely by ourselves) and current approaches to improve the managing experience are either:
³ Decentralization at scale refers to the fact that decentralized system are more robust against an important set of cyber attacks and availability issues but only when the underlying system is big enough (i.e. have enough nodes).
The first two of these usually come from good design in peer-to-peer network infrastructure and consensus mechanism but ONLY when decentralized at scale³. The last one is desirable for obvious practical purposes, and the three of them together shall be called in the rest of the document as the three conditions which should not happen when solving this issue.
To see this more clearly, let us simplify the connection by dividing each step into layers, superficially explained as:
