Decentralization is like a puzzle, with various technologies and protocols acting as key pieces to form a coherent image. Blockchains, for instance, address aspects like authorization, authentication, and accounting. They determine user identity, confirm its authenticity, and monitor expenditures. However, these are just three pieces of a complex picture.
One missing piece is related to browsers, where decentralized connectivity is still evolving. While used by billions daily, browsers are still lagging behind in Web3 functionality. At Syntropy, we’re focused on fully decentralizing access to blockchain data through the Data Layer. To achieve this goal we must understand and address the inherent centralization issues related to browser protocols. Towards this end, we’re exploring the potential of the WebRTC protocol and seeing how it can shape browser-based communications.
The Challenge of Decentralized Connectivity in Modern Browsers
Modern browsers primarily serve as access points to web applications. This involves fetching resources from the network and executing code within the browser environment. Decentralizing the resource retrieval process can potentially enable browsers to run decentralized software.
However, inherent browser protocols lean towards centralization:
- DNS Addressing: Leans heavily on centralized services, making the naming system susceptible to centralized control.
- CORS: A security feature where browsers limit resources fetched from particular sources, essentially curbing potential threats but also inhibiting flexibility.
- Security Authorities and Certificates: The current model is fully centralized. And while self-signed certificates exist, they aren't feasible for wider use. Modern browser security heavily relies on these centralized certificate authorities (CAs)
It’s also important to note that CAs can and have been exposed to vulnerabilities, from hacking attempts to IP address manipulations. Moreover, the centralized nature and frequent governmental oversight make them potential points for surveillance or control. This consolidation of power and associated risks highlight the need for a decentralized approach to web browser security.
With these constraints, the WebRTC protocol acts as a tool for decentralized communications. Most other alternatives are bound by rigid rule sets inherent to browsers. Our vision is simply to craft a solution that integrates with traditional browsers and ensures secure, decentralized communications for users.
Decentralizing Connectivity: A Deep Dive into the WebRTC Solution
We use WebRTC to achieve true decentralized communication. It’s designed to work as a peer-to-peer protocol, allowing browsers to reach any peer directly via an IP address, port, and connection hash, the latter of which is core to WebRTC security. This combination circumvents the DNS system and the certificate authorities highlighted above.
However, there’s a caveat with the protocol. It’s designed as a secondary protocol, i.e. the connection port and hash are agreed upon beforehand via other browser-supported protocols. We don’t want to use the other protocols, and to utilize WebRTC we need another connection beforehand, which would be based on centralized security.
We need to achieve secure communications without that. At this point, we needed to get a little creative with the implementation. But we also need to look into the separate components and ideas that made the solution happen.
Understanding Peer-to-Peer Communication
Being a near-opposite approach to centralized communication, P2P relies on performing a number of connections to other similar or same nodes to maintain a stable network. This is the model that our Broker network operates on. Using such a network as a client poses an interesting challenge as well.
Usually, in a centralized system, the client can always be sure that one address or another will point to an intended service, that address (DNS) is maintained by the service developer or administrator. In a public P2P network, the client may not rely completely on a single node working the next time the client tries to reach it.
Therefore a number of addresses need to be kept, to ensure the client can find a working service node. Glossing over the details, the point is that the addresses are pre-shared to the clients in some fashion. That means we can pre-share the WebRTC connection hash with the address, but we cannot rely on it for security anymore.
Reimagining Modern Security
If we peel back modern security, it’s entirely based on asymmetric cryptography. Meaning each peer produces a keypair - public and private keys, to allow them to establish a secure connection. The algorithm in question is the Diffie-Hellman key exchange algorithm.
Two peers exchange their public keys and then use the local private key and the other peer’s public key to produce a symmetric key. This is performed on both ends to produce the exact same key. This allows for a secure channel to be established over an insecure channel.
We can use an insecure channel to establish another secure connection via the Diffie-Hellman key exchange.
What the End Product Looks Like
We combine those ideas and use the pre-shared connection hash to allow the client to establish an initial handshake connection via WebRTC without any prior address negotiation and establish a new secure connection via the Diffie-Hellman key exchange.
So all in all the feature allows creating secure WebRTC connections to other peers only by knowing the address of the peer beforehand, with no pre-existing setup. This allows us to run decentralized applications that use decentralized resource delivery right in the comfort of your own browser.
Redefining Decentralized Applications with WebRTC and Syntropy
Incorporating WebRTC with the Data Layer is opening the door for a generation of backend-less applications. Imagine a decentralized app rich in features, with a clean user experience like Facebook or Instagram, but without the need for extensive server infrastructure. This is now possible with WebRTC and the Data Layer.
With direct data streaming to browsers, 'live' decentralized platforms can now contain dynamic, user-generated content similar to what the majority of the world is used to in Web2 platforms. It's similar to the evolutionary leap from the static, first-generation internet to Web2, but without the limitations of centralized infrastructure.
Take a decentralized chat application, for instance. Powered by the Data Layer and WebRTC, this kind of application enables real-time, peer-to-peer messaging without the need for central servers. These types of approaches and use cases are what’s possible, making decentralized browser-based dApps as user-friendly as Web2.
Building with Browsers and Beyond
Decentralization is a complex puzzle requiring many different shapes, sizes, and colors of pieces that paint a perfect picture. While certain tools like blockchain fill in certain gaps, WebRTC is filling in the missing pieces related to web browser connectivity. As true peer-to-peer browser communication expands with WebRTC, so will the access and usability of Web3.
At Syntropy, we are dedicated to making tangible, incremental progress towards completing the entire decentralization puzzle. WebRTC is just one towards the bigger goal, and we’re supporting builders who share the same vision. We invite you to delve into the Syntropy Builders program and collaborate in building the next generation of democratized on-chain data access through Syntropy’s Data Layer.
.png)