I know, I know. You read my previous post responding to Dan Larimer’s launch of ClarionOS where I said that we were not getting rid of blockchain, although, I NEVER said that we were going to use a blockchain indefinitely or in a major way. One thing you may have noticed in the dWeb whitepaper, is where I spoke on using a blockchain for governance, which still might be the case, but, we’re doing everything we can to move on from blockchain. In my previous post, I tipped you guys off to our release of DRE (Distributed Runtime Environment), which would allow a blockchain or any application, to be ran within “distributed containers” across the computers of peers who agree to allow the container to utilize some of their computer’s resources. I know that sounds crazy and believe me, it is. But, we didn’t create DRE for blockchains. We created DRE for all kinds of applications, although, as exciting as DRE is, that’s not what this post is about. I wanted to talk about our move away from blockchains, yes, blockchains, and how dWeb’s revolutionary DHT is rapidly moving us towards a post-blockchain era.
==== WHAT IS A DHT?
You can think of a DHT as a distributed database, because, well, it is. DHT is short for “distributed hash table” and there are many kinds of DHTs including the Kademlia DHT that is used by distributed networks like dWeb, IPFS, Hyperspace, Holochain and BitTorrent. In fact, DHTs come in a plethora of colors, shapes and sizes, all designed to handle some sort of “data physics.” For example, dWeb’s core DHT, is used to store dWeb network addresses, along with the peers that are seeding the data related to those network addresses, although, a DHT like any database can be used to store whatever you’d like. Not to mention, it can also be used to validate data before it’s distributed and stored across the DHT itself.
==== HOW DO NODES ON A DHT GOSSIP (SPEAK)?
A DHT is literally a key-value store-like abstraction, that sits on top of what is ultimately a distributed binary tree, where the key is a hash of something and the value is whatever you want to be related to the key.
Consider the following example:
```
KEY VALUE
====== ================
af32ad9a9d729…. world
```
NOTE: In the above example, the key is a hash of the world “hello” and the value is “world”. If I do a lookup for the hash of “hello”, the DHT will return the value “world”.
To add to that, each node on the DHT network keeps a finger table of other nodes that belong to the DHT. In fact, thanks to advanced network traversal techniques used within DHTs like Kademilia, nodes are able to locate each other in a very efficient way. More importantly, the implementation of NAT traversal strategies gives DHT nodes the ability to easily speak to each other even if they’re behind a firewall or without a public IP address. NAT traversal is an important feature, considering how data is distributed across the DHT and the fact that most personal computers, unlike servers, are indeed behind some sort of firewall or without a public network address to begin with. In other words, getting to these nodes would be quite difficult if NAT traversal were never used. In fact, if DHTs didn’t utilize some form of NAT traversal, a DHT would probably never work correctly on a peer-to-peer basis since a majority of the DHT’s users (nodes) would be personal computers utilizing some form of a home-based network.
==== HOW IS DATA STORED ON A DHT?
Since nodes can locate each other, they can also exchange data amongst each other and query each other for data as well. Just like nodes can be located in an efficient way, so can data, along with the node that is storing the data. Which brings me to the next point, who stores the data? Well, that’s what makes a DHT so unique. A DHT is a very lightweight software that utilizes potentially millions or even billions of peers to store its data. It all depends on how many users have joined the DHT. Unlike a blockchain though, peers only store a portion of the network’s data which is ultimately divided by some variable amount amongst those peers. For example, if I created a DHT that had four peers, and two entries, both entries could be redundantly stored across its four peers if that was indeed how I chose to design my DHT. A DHT’s ability to redundantly distribute data, is perhaps its greatest feature and those who develop DHTs have the ability to configure a data redundancy strategy for their DHT, depending on the type of data it’s handling. Where, if one peer leaves the network, the data that peer was holding is moved to another peer and so on. It’s actually normal to see peers joining and leaving a DHT, and this does little to affect the operations of the DHT itself. In fact, a DHT is specifically designed for this sort of activity. As long as a DHT has a good data redundancy strategy, a DHT will never have to worry about data loss. In other words, the data entries within it will always be available across the network, spread out across its available nodes.
==== HOW DO USERS BECOME A NODE ON A DHT?
So who are the users using the DHT? Well that’s the beautiful part. A DHT, unlike a blockchain, can be built into an application. For example, dWeb’s DHT software, along with dSocial’s DHT software are built into dSocial’s core application code. Considering both DHTs are less than 500 lines of code and Node.JS modules can be imported into any application, they are very lightweight and easy to integrate. More importantly, by running dSocial’s application on their device, users are automatically joining both DHTs by default. This is because in order for users to distribute data on either DHT, they have to become a node on the network and those who use applications for longer than 30 minutes, end up becoming persistent nodes on whatever DHT(s) the application is utilizing. This allows for dWeb’s DHT and dSocial’s DHT to grow in size much faster than a blockchain ever could, considering how complicated the blockchain installation process is and how each participant in a blockchain network has to store all of the network’s data. Not to mention, having to compile a blockchain and keep its daemon running is a very intensive process — just ask your CPU. This is simply not the case with distributed hash tables.
==== SO WHAT ABOUT CONSENSUS?
So I guess you’re wondering, is there anything a DHT can do that a blockchain cannot? Surely this lightweight solution has to be lacking somewhere! That big old diesel truck has to be more efficient and run faster than its electric counterpart, right? Wrong. I will say it again — DHTs can be built to handle anything, whether it’s cryptocurrencies, smart contracts or even distributed file systems, as you are seeing with the dWeb today and dDrives. In fact, what you will see momentarily, is that a DHT can be used to store Web Assembly (WASM), that is ultimately compiled from smart contracts just like the EOS blockchain does. That Web Assembly can then be executed and ran in a VM, where the results of such are stored in specific DHTs, specified by the contract, just like a smart contract developer on EOS would specify a data schema and define their database tables within a smart contract for on-chain storage in relation to actions executed within those specific contracts.
Ok ok ok.. yes.. blockchains are great when it comes to consensus and the many consensus algorithms out there like POW, POS and DPOS allow us to do so many things, so how do we replace this? The truth is, we don’t have to and this view is shared by many leading scientists in the field. For starters, blockchains are great for consensus, but in truth, do we really need to have mass consensus when it comes to the data the users of our applications are generating? In most cases, we don’t. In order to have data integrity, all nodes on the network do not have to come to a finite agreement (consensus) on an absolute order of events. Atoms, molecules, cells and our bodies all function normally in the real world and are able to maintain the integrity of their individual and collective states without any sort of “global consensus” or “global ledger.” Just like the General Theory of Relativity teaches us, there is no real sequence of events, just sequences that relate to a specific vantage point. If applied to distributed data, this will lead us to move beyond blockchain and its intensive processes that simply bring us to a singular vantage point, rather than a “holographic” view of our application’s data, which can potentially take on thousands of different vantage points. This is why we’re able to say goodbye to blockchains for most use-cases and why the future is so bright and well, yes, distributed.
==== INTRODUCING DMESH
We have been working on dMesh for some time and if any of you have been around this project for longer than 2 years, you’ve heard of dMesh in our Telegram rooms, and have probably heard me mention it at least a few times. In fact, dMesh is prominently featured on the new I AM Freedom website (https://iamfreedom.us) — I simply never spoke on what dMesh actually was. Some knew that we were attempting to build some sort of “mesh-like” network that would allow folks to launch a web that completely separated us from today’s overly centralized physical Internet infrastructure. While that sounded great, after taking a closer look at this, we determined that it simply was too big of an undertaking. The goal became to build a way for users of the Internet to exchange data without any middle-men or bottlenecks. Through our experience working with DHTs over the past few years in our roll out of the dWeb, we have gained quite a bit of knowledge as it pertains to DHT networks and how they can be utilized for much bigger purposes than peer discovery, as is the case with the dWeb today. In fact, we determined, beyond a shadow of a doubt, that the world would simply be a better place if there were DHTs on every corner — and I’m not joking.
In fact, what if DHTs could talk to other DHTs? Or what if one DHT could utilize the capabilities or data patterns of another DHT via some sort of DHT bridge, where each DHT could validate data via data that the other DHT possessed? If all DHTs could exchange data and query each other, and then validate data based on data that the other DHT network possessed, you would have one massive, global network capable of pretty much anything under the sun. In fact, you would have a massive global network, ran by millions of personal computers, that the ISPs simply couldn’t control and where data could move freely and organically. More importantly, a network like this could scale the world with ease — and we could do away with worrying about “transactions per-second.” It’s important to note that each of these DHTs are separate networks, like separate blockchains, which would handle their own “data physics”, a.k.a. their own data validation, just like separate blockchains are unrelated, if they both have different data physics and consensus rules.
dMesh will soon allow anyone to launch their own DHT and what we’re calling “private chains” (more on this in a second). Each DHT is configurable by developers, where they can configure a DHT’s data physics, as well as bridges with other DHTs that they may want to exchange data with or inherit the capabilities of. For example, if a DHT is created for the purpose of storing social networking data, then you would set the validation rules accordingly. In fact, you could bridge with a DHT belonging to another social network as well, so that your application could utilize its data. Keep in mind, all of this is done without massive servers and mining equipment. We do live in 2021 after all right? It’s simply just a massive mesh network of people’s personal computers and how in the world could anyone take that down? They couldn’t. And did I mention how eco-friendly this is?
==== THE INCEPTION OF PRIVATE CHAINS
dMesh isn’t an end-all though. While it certainly represents the “layer zero” that developers like Dan Larimer have been teasing about, there is much more to dMesh than just a bunch of DHTs. Enter dDatabase v10, or as we call it — dDatabaseX. dDatabase has been around since the inception of the dWeb protocol and is essentially an immutable append-only single-writer ledger that can be exchanged between peers. In a way, it’s a private blockchain for a single user, where that single user is able to manage the integrity of their data alone, along with their own sequence of events. That data is then sent on to different DHTs for validation, depending on the application they’re using, and validated by the nodes on that particular DHT, depending on that DHT’s validation rules (its data physics). While this may sound confusing, that’s because you’re probably used to a blockchain environment, which is considered to be data-centric, whereas a dMesh environment is user-centric. Users or as they’re defined in similar systems, “agents,” manage the individual and collective state of their own data via dDatabases (private chains) on their own machine and then that data is propagated to different DHTs and signed by other remote users (nodes) of the accepting DHT network, according to that DHT’s data validation rules.
==== NO MORE BOTTLENECKS & THE BLOCKCHAIN-LESS CRYPTOCURRENCY
So what does all of this mean? It means we’re able to do everything we’re already doing with blockchains, without dealing with the bottlenecks that blockchains create, nor do we have to deal with a singular state when it comes to our data. Rather, data is freely distributed around the world naturally, in a way that is validated and signed by the users of the applications themselves. At the same time, data is dynamic and can be viewed from multiple vantage points, just like information is distributed and viewed in the real world. But what about multi-party transactions? If data integrity is handled by an individual user and then broadcasted to a DHT for validation and signed by other DHT nodes, how can multiple parties be a part of this process? This is where things get interesting and how our all-new blockchain-less cryptocurrency came about. It’s actually quite easy for 2 or 3 parties to come to consensus on a transaction, considering they all agree to take part in it. Each party would sign the exact same transaction, each linking to their previous dDatabase entries and of course, each of these would be propagated to a specific DHT, validated and signed by various DHT nodes. It is important to note that this does force each user’s private chain to move from a singular vantage point to a multi-vantage point, as consensus does happen on a small scale in this particular case but only amongst the users who simply agree to take part in the transaction.
This has given way to a new coin we’re calling DWEB, and yes, all transactions are located on the DHT, considering multi-party transactions, as I just explained, are propagated to a specific DHT. In this case, the DHT is for the DWEB currency. In fact, creating a blockchain-less currency is as easy as cloning the dMesh-based smart contract for DWEB, launching a custom DHT and configuring your currency. Transactions are signed and propagated to a DHT by the parties involved and a complete ledger is available via the DHT. One may say that transactions could be lost this way but, as I stated earlier in my post — ONLY IF YOU DESIGN YOUR DHT IN A WAY WHERE THIS IS POSSIBLE. Your data redundancy strategy is key. As long as there are many people using a currency, there will be nodes on its DHT that share all of the data related to its DHT. If thousands of holders are sending coins daily, well, there are thousands of nodes that will maintain the existence of the currency’s ledger.
==== DMESH SMART CONTRACTS & THE DMESH COMPILER
Just to reiterate, the users of applications all write data to their own private chains (dDatabases) and this data is then propagated to an application’s DHT, validated by potentially several DHT nodes and signed by those nodes, according to the rules set forth by the DHT’s creator (the application developer), which is in-turn referred to as a DHT’s data physics, or in short — it’s DNA. But what about those smart contracts I was bragging about earlier… Well, I’m pretty sure you have already figured out by now that you can probably store smart contract code on a DHT, considering you can store anything. Consider the following example:
```
KEY VALUE
========== ======================
smart-contract-name <binary formatted WASM>
```
The key is a hash of the smart contract name, which can easily be looked up, as long as the smart contract name is provided to the DHT. The value is the WASM code related to the contract, formatted in binary. We will soon release a WASM interpreter that can interpret WASM stored on a DHT. This will help us move all smart contract functionality from the ARISEN blockchain to a customized DHT built for validating and storing WASM-based smart contract code, which can ultimately be executed by any WASM-ready virtual machine, just like WASM code stored on ARISEN is executed by RSN VM (https://github.com/arisenio/rsn-vm). Smart contracts can be written in JavaScript and using the dMesh Compiler, can be type-checked and compiled into dMesh-valid WASM easily. So where is data associated with actions stored? A user’s private chain and then on DHT(s) mentioned in the contract’s data structure of course! App developers will be able to define a specific data structure for their application within the contract, which will be used for action-based data storage. A smart contract can also utilize a specific DHT, which acts as a DPKI, for verifying which key is indeed supposed to sign for the action.
==== USER AUTHENTICATION & AUTHENTICATOR DHTs
It shouldn’t come as a shock at this point that DHTs can be used as Decentralized Public Key Infrastructure (DPKI), just like blockchains are, which means they can be used for user authentication. Imagine a DHT that was used solely for user authentication, where users could sign the creation of a “mutable” entry on the DHT, that they could then update at any point as long as they possessed the keys that were used to create the original mutation (sequence 0). The DHT would ensure that data was submitted in a specific format, where the key was a hash that derived from a username and the value was an object that contained the public keys for named-permission levels that were associated with the username.
Imagine the following entry:
```
KEY VALUE
======= ==============
@username {
owner_permission: DWEBa54da43…,
active_permission: DWEBf39eb03…,
signature: af73ad81…
}
```
Considering DHTs can be bridged to work together, a smart contract could be designed to use one DHT for user authentication, and another DHT to store data related to executed actions. In a dMesh-based smart contract, actions are actually referred to as “Mutable” actions, which in turn must be signed by a private key. This allows for the original “mutator” to edit this data, as long as they can sign the new mutation with the original private key that the previous or original sequence was signed with. With that said, a smart contract could be designed to verify whether or not the digital signature related to a mutation, belongs to a particular user’s public key that’s stored via a DHT used by a dMesh Authenticator DHT (A DHT designed for DPKI). This should open your mind up to the possibilities here. This means app developers could store and manage their own users, via one DHT (a dMesh Authenticator DHT), which has its own validation rules for user registrations (DHT entries) and a dMesh Storage DHT (a general dMesh DHT), which is used for storing data related to actions executed via a smart contract, which by the way, are stored on dMesh’s smart contract-ready DHT. By bridging both DHTs, each is able to query the other for data, which could also be used by each DHT’s built-in validates. At the same time, the contract can ensure that the action’s executor, is indeed the private key holder related to particular user/permission-level on a particular dMesh Authenticator DHT, as specified by the contract developer. In other words, it would go something like this:
1. Within a smart contract, a developer names an “authenticator_dht” and a “storage_dht”. The authenticator_dht is a dMesh Authentication DHT and the “storage_dht” is a dMesh Storage DHT, both configured by the developer.
2. Within the contract, both DHTs are bridged together using a “dMesh Bridge” so that they can query one another via a function within the contract itself.
3. When executing a smart contract action, a user would provide their username and other required parameters. Note: Internally, the smart contract action will require a specific permission level.
4. A lookup is made by the contract, to the “authenticator_dht” for the username matching the username that was provided by the executing user and the “authenticator_dht” returns data matching the username “key” to the contract.
5. The user executing the action signs the action with their private key and stores in their private chain.
6. The contract checks the digital signature of the action to see if the signer is indeed to possessor of the given username’s private key, per the public key that’s stored on the “authenticator_dht”.
7. If valid, a mutation on the “storage_dht” is created, along with the signature and this data is then distributed amongst a handful of nodes that exist on the DHT.
8. Any user of the distributed application related to this contract, can now query this data from anywhere.
Keep in mind, there are no servers involved in this process and it is completely organic and autonomous. While I’m leaving out many technical details here, I wanted you, the reader, to wrap your brain around how this works and how we’re able to achieve the same things we already do with blockchains, in a blockchain-less environment.
==== ZERO INFRASTRUCTURE COSTS
By eliminating the ARISEN blockchain from dWeb’s core systems, we are truly blockchain-less but more importantly, application developers no longer must worry about having to pay for smart contract executions. This means no more RAM, CPU or NET fees on blockchains like EOS or Gas fees on blockchains like Ethereum. There is no reason for metering the system, since there isn’t truly a limit on the number of resources an application can use, considering data on dMesh is completely distributed and dMesh cannot be abused due to its architectural design. This allows developers to operate with zero infrastructure costs, which in most cases, will equate to zero infrastructure costs. This allows developers to focus their profits solely on developing and marketing their application, instead of paying for blockchain-based storage costs.
==== BLOCKCHAIN-LESS GOVERNANCE AND ELECTIONS
Some of you may be wondering what will happen to dWeb’s Constitution or its governance or how we will be able to build some sort of consensus algorithm on top of dMesh that prevents illegal activity. Well, while I said we don’t necessarily need consensus for everything, I do believe we need consensus when it comes to the deciding which content that’s distributed across the network, is appropriate or quite honestly, legal! In the future I believe our DHTs will be able to do this via some sort of A.I., but in the meantime, a governance is needed. While certain folks may argue that this introduces centralization into the network, I see it as a way to keep the dWeb safe and ensure that it’s not turned into some sort of “dark web.” Solutions out there that decide against this sort of design will ultimately regret it. I’d hate for them to find themselves in prison because they wanted to simply innovate something or for providing freedom to others. If I could give any of those guys some advice, I’d have to remind them that there are people in federal prison who are here because they simply fought for the freedom of others. They did all the right things and had all of the right intentions but that did little for their own freedom. As one lawyer said to me long ago — “Jared, it doesn’t pay to be a martyr” — and he was right. I meet prisoners like this from time to time and I certainly don’t want to end back up in a place like this either. I’m done with this lifestyle, but in truth, I never intended to experience it. For this reason, we are working on a new blockchain-less Governance system and bridging certain “root” DHTs that in-turn power distributed network addressing and dWeb’s all-new domain name system, which can be used to block this sort of activity from being accessed in browsers like dBrowser. In-turn, other browsers can choose to integrate with these systems as well. That means building a new blockchain-less election system, as well as a blockchain-less reporting system, that will ultimately give the community a way of making their voices heard. I genuinely believe that’s crucial to the mass adoption of dWeb’s platform.
===== CONCLUSION
So yes, it is true. The dWeb will soon dump the blockchain for dMesh, but this was something that had to be done. When it comes to the freedom of information, as well as the performance and user experience associated with distributed applications, there is not a single framework out there that can help you achieve higher benchmarks in any of those three areas, than the frameworks that dWeb and dMesh provide for. By moving away from the blockchain, we are not only creating the ultimate playground for distributed application developers but we’re also making the world a better place, by helping transition people away from technology that equates to a tremendous amount of power consumption, to a technology that hardly has a carbon footprint. Beyond that, we’re moving away from the bottlenecks that blockchains create, the need for servers and the need for maintaining a single global state for our data. Considering a blockchain was intended to be a distributed database full of data that was deemed valid by a network’s peers, dMesh is a network of many distributed databases, each of which can handle inter-process communication amongst each other almost effortlessly, which in-turn allows each of these databases to reach consensus based on their actual validation rules (DNA). As I pointed out earlier in this post, since one database’s validation rules can utilize another database in the validation process, this inter-process communication creates a massive mesh network of network participants, that will ultimately grow, as the number of apps built on top of the network grows. In other words, it will grow much faster than a blockchain ever could.
In closing, you may be wondering when all of this is going to launch. Well, I have great news — it’s launching today. We are beginning the rollout of dWeb 3.0 today, which includes dDatabaseX, dHub, dTree and our all-new networking libraries. I will begin rolling these out and explaining each system in a new multi-part Medium/Hive series titled “Let Freedom Stream”. The first post of the series will debut tomorrow, announcing the series and what you can expect. Some of you may remember the first time I debuted this series back in 2018, and days later I was arrested. If so, you’re not having deja vu.
In the meantime, grab some popcorn. It’s our time to shine. The question is, are you excited?
Onward through the smog!
Jared Rice Sr.
