Web3: From Principle to Protocol, Bare-metal to Space
APOLLO WEEK#1 - Why we're building Ethereum-first, and updates
We could use your support! If you agree with what we’re building, we have a grant live for this round of matching. Any support, no matter how small, is appreciated (especially considering how QF works!)
At Guer, we have a pretty optimistic view of what Web3 can bring to our next-gen digital lives. We also recognize that we're standing on the shoulders of giants; what we're solving isn't new, just new to decentralized computing. In many introductions, we'll hear, "Oh so, isn't that what "project X" is doing?"...so we'd like to take this opportunity to elaborate a bit on some of the principles we've worked hard to adhere to.
Especially recently (2019), there has been an explosion of blockchain networks. Some serve a very specific purpose, like Fully Homomorphic Encryption, while others believe their scaling solution is an "Ethereum Killer" and could displace Ethereum as the leading Turing-complete blockchain network.
When we began working as Guer, we decided early on that we would focus almost entirely on Ethereum. We were (and remain) of the belief that a blockchain must first be sufficiently decentralized, or resilient, achieved through volume and distribution. Furthermore, Ethereum's economics are elegant, functional, and mostly understandable.
If looking at incumbency vs innovation, even in 2018, we were convinced that while far from perfect, Ethereum had the capacity to integrate new concepts and technologies, either directly as a smart contract, as a Layer 2 pinning to Mainnet, or eventually in Eth2.0. The general notion of hundreds of small blockchains performing critical but niche tasks for a greater Web3 seemed unlikely.
As such, everything we have built is "Ethereum-first", e.g. Solidity + EVM compatible, which in 2018 was a mid-to-long term view. In the short-term, it would have been easier to use an “Ethereum Killer” for transaction speed or a version of WASM. As a protocol, we believed we needed to be as primitive as possible for the network. Scalability, Cost, etc would be bridges crossed at a later date.
So often, when asked, “Doesn’t Project X do that?”…the answer is “Yes, kind of...” When building something as potentially critical as P2P encryption for Web3, do you want to rely on a network of a few hundred nodes, virtualized on some AWS hardware? Or a network with questionable token economics, subject to the whims of DeFi trends like flash loans or wrapping? Probably not.
We believe that the patience, research, and discipline the Ethereum community has demonstrated over time signals a much longer time horizon, one which will provide the most reliable bedrock for Web3 security. And if not, our logic still holds outside of the EVM and Solidity!
A typical reaction to the word "Trustless" has been, "But if Trust is good, isn't Trustless bad?" Unsurprisingly, this is the sort of binary, yes-no thinking we need to expect. It does not take long, however, to explain that "Trustless" does not equal "Untrustworthy"; it fundamentally changes how trust is required to participate. [This was covered well in KERNEL/APOLLO's Module 0]
“You need 100% Trust to Ride”
Participation in Web2.0 is predicated on trust. To use a cloud application means to store/provide your data on a company's hardware, subject to their terms, needs, and mercurial whims. It means to trust an organization so wholly that your trust becomes an assignable, transitive property (If Alice trusts Company A, and Company A trusts Org X & Org Y, Alice trusts Org X & Y).
Much of Web2.0's infrastructure works the same way. Complex challenges like digital identity, scalability, and security were built after-the-fact, and typically resulted in functional, but centralized protocols and services, often run as for-profit private businesses. Examples include DNS Resolvers, TLD Admins & Registrars, Certificate Authorities, and ISP NATs. The average end user is surprised to learn that at least 2 private companies are involved when they connect to their bank's website with the little lock in their browser.
For Web3, we want security to be core to how we interact. For the transport layer, all data in transit should, by default, be encrypted. Currently most of Web3 relies on TLS, an adequate Web2 standard, tied to IP addresses, subject to Certificate Authorities or self-signed certificates, and vulnerable to hypervisor and memory attacks.
Web3 needs Web3-native security
Our handshake stands on the shoulders of giants like Diffie-Hellman, but incorporates innovations of Web3:
Ethereum (ECC Keypairs) Addresses as Identity, further verified as needed by ENS/Unstoppable/HNS
Smart-Contract ID Verification and Handshake Facilitation
Networked Trusted Execution Environment (TEE) key generation and distribution for bare-metal security
The result is any person, contract, or device with an Ethereum address can participate in a secured session connection, completely P2P, without concern for a variety of attack vectors faced by Web2.0, like hypervisor or DNS Man-in-the-Middle attacks.
For a protocol to be widely adopted, it should be elegant, frictionless, inexpensive, and easy to implement. Particularly in trustless environments, the code itself needs to be trusted, and therefore reviewable, verifiable, and in the case of TEEs, attestable. We support and advocate for open-source protocols; they are critical to the development, adoption, and ultimate success of Web3.
We want to encourage other projects and teams to rely on our protocol, build it natively into their applications, and leverage its agnosticism as a common means for interoperability. With review, use, and community, we hope to evolve the protocols alongside Web3, with the guiding principles of decentralized trustlessness.
If Web1.0 was highly localized (See C:/Anything) as terra firma, and Web2.0 was "the cloud", it's not surprising that folks like Protocol Labs or Fleek are invoking the imagery of "Space" for Web3. In decentralized systems, hardware can be anything, and at times malicious. TEEs and smart contracts empower us to "Not trust, but verify" from the very bottom of the stack, e.g. The CPU, up.
That's why we are building protocols from principles, and know to succeed in space, we need to be well-founded in bare-metal security.
Have questions or comments? Shoot us an e-mail at firstname.lastname@example.org
Every chance we have to explain and discuss these concepts helps us improve our understanding too!
APOLLO WEEK #1 UPDATES
In week 1, we finished a prototype to help test the handshake protocol and encryption. Using the handshake, we built a simple asynchronous message system using smart contracts, IPFS, and a GoLang mock-up of a TEE.
As a result, any party (user or contract) can send, receive, and store encrypted messages using AES keys generated off-chain in a trusted execution environment. The encrypted messages are stored on IPFS, and the identity verification, access management, and handshake facilitation are handled by smart contracts. This prototype helped us confirm how the EVM would interact with TEEs and IPFS.
Our end-goal for APOLLO is to have the code as ready for production as possible. Our strategy is as follows:
Find an open-source Web2.0 application that is easily modified and deployed in a typical Web2.0 context
Modify that application to a) store data on IPFS b) verify ID based on EC Keypairs c) interact with the EVM
Begin building out production-ready versions of the microservices; that is, with as few cross-service dependencies as possible, and web2.0 developer-ready code, on test net, using GoLang TEE stand-in
Integrate Networked TEE service
Testing, Peer Review, and Auditing
Our goal for end of Apollo from a non-technical standpoint is to be Investor- or Grant-ready, whichever is more appropriate. (We're passionate about this work, and seek the means to focus full-time!) To this end, we would like to be intentional with our time with mentors and fellows, identify the right questions, and pursue the right answers!
Reviewed and identify mentors who can help validate our concepts, and shape how they fit into the greater Web3 ecosystem
Dedicate time to our substack, detailing not just progress, but principles and technical overviews as they pertain to the APOLLO syllabus and our project
Support and discuss with interested Fellows, both to understand how our project could contribute to their success, as well as how we can better meet their needs as a protocol
Financial modeling (😢): Projecting fee structures for encryption computation, as well as a way to sustainably continue building and supporting the protocol
Research (😉): Our use of TEEs in a TLS-like handshake brings us very close to enabling storage- or network-side encryption (aka decentralized proxy re-encryption). This would be a decentralized service that trustlessly re-encrypts data for distribution, reducing Web3's dependency on client-side encryption or gateway services. Further research into MPC schema as a means for TEE provisioning is required, which we're looking forward to as time permits
Thanks for reading! If you’d like to follow along, please subscribe. We’re aiming for at least one update per week, but may break some of these longer posts into technical overviews.