Blockchain enthusiast developer and writer. My telegram: ksshilov
Learning a new technology can certainly be overwhelming, especially when you’re a developer who already has a lot on your plate. But when it comes to looking out for the future of your career, even the busiest of developers should understand how important it is to stay current with the newest developer trends. Blockchains have, quite simply, revolutionized many spaces thanks to the implementation of dApps. But can blockchains stay at the forefront of revolutionizing technology if it becomes stagnant? Blockchain primitives will have a huge impact on the ever-changing development of distributed ledger technology, and it will all boil down to one thing: protocols.
When it comes to advancing any technology we have to first take a look at the base parts, the primitives if you will. A good place to start is with protocols, since they are fundamental in the technologies we already understand; they will probably become even more integral in technologies of the future. There are two categories for protocols layers, according to Joel Monégro of Union Square Ventures: “fat” and “thin”.
Fat layer protocols refer to those that hold the most importance in their respective field. In traditional technology, fat layer protocols are the layer of applications that interface between data and the people. The most obvious examples would be applications like Google, Facebook, LinkedIn, and similar websites. The layer that these applications run on, in traditional tech, is known as the thin layer and consists of HTTP/HTTPS, TCP/IP, and similar protocols.
In this setup, the fat layer is dominated by centralized organizations that have access to and own all of the user data, and users are forced to enter their sensitive data into many places over and over. Everytime you buy something from a new website, create a new email account, or sign up for a new service you have to give this data up time and time again. But the blockchain is trying to shift the thickness of these two protocol layers, and in an ideal world we’d have all of our sensitive data in one layer and applications in another.
Blockchain technology is celebrated for protecting user data through decentralization, but how exactly does it work behind the scenes? In the blockchain, the fat layer is comprised of various protocols that can be used by a large number of applications, while the applications themselves make up the thin layer. Because of this reversal of where the fat layer is, a blockchain is able to better manage a user’s data since it’s kept in a secure, decentralized place instead of in each and every different application. The dApps in the thin layer can access the data when given the appropriate authorization, but the dApps themselves never control the data exclusively like they do in Web 2.0.
DLT primitives are common in many different chains and act as the underlying building blocks that help everything run more smoothly and efficiently. They exist to make the developing process easier, giving developers chunks of code that is already formed so that they don’t have to write everything from scratch every time.
But as intuitive as they are, they are still lacking in certain areas. In the Bitcoin blockchain, for instance, the primitives aren’t nearly as extensive as they could be, which thus limits the usefulness of the chain itself. Bitcoin isn’t built to allow for dApps and other programs to run on top of it, which is why the primitives that exist in its chain are more simple.
There are nine DLT primitives that are especially important, and we’ll discuss each in brief detail:
Other blockchains, such as Ethereum, EOS, and Tron, have plenty of primitives to help programmers remain consistent, but there is a tradeoff for that freedom. In these dApp chains, programmers have dozens of primitives to choose from when programming their dApps, but they don’t have any overlying guidelines that they have to specifically follow.
There are standardizations in these chains; for instance, in Ethereum there are ERC-20, ERC-223, ERC-721, ERC-777, and more. These standardizations exist to give programmers a choice; they can build their dApps however they want using primitives, but if they want to make their dApps easily integratable with other dApps, chains, and developers’ work then they have to abide by a standard.
The different standards have different purposes, but when tokens ride the line between purposes the developers often struggle to find the appropriate choice - instead of adapting the blockchain to fit their needs, developers are forced to adhere to preset standards if they want their token to be able to easily interact with other tokens.
One easy way to think about this conundrum is to imagine there is a room full of toys and you are trying to build a specific thing. In this room you have action figures, Legos, Lincoln Logs, dolls, and more. With this wide assortment of toys you can certainly create unique scenarios, intricate scenes, and more, but what you gain from diversity you lack in functionality. These toys, although they can all be used together, do not work together and cannot create strong, tangible results. If all of your toys were Legos, for instance, everything you could create would be designed to easily work together flawlessly.
In this example, a room full of miscellaneous toys is the current ecosystem for dApp programming languages, and a specific toy set leads us to...
There are a few newer languages that are attempting to try something different by changing the entire approach that developers take when it comes to programming new dApps. Waves’ Ride and Libra’s Move are two great examples of languages using blockchain primitives to move the decentralized dApp ecosystem forward to help us achieve Web 3.0 (the next generation of how users and applications will interact over the Internet).
Waves is a forward-thinking company that is pushing to create an atmosphere where developers using their platform can program in chunks. They already have a working blockchain, programming language, and they specifically created blockchain primitives to ensure that everyone is on the same page. Libra is following a similar path, but with more emphasis on helping developers create dApps that move the Libra currency from one account to another. Until we see Libra in action we won’t know exactly how useful their concepts are, but since Waves and Ride are already live we will push forward with them for the rest of this article.
In Web 3.0, users will be in control of their data while companies and dApps will be forced to work around this central sphere of user control. As we mentioned earlier, the current Web 2.0 exists with applications being the fat layer and protocols being the thin layer, which leads to an overall degraded user experience because we are not the fulcrum. Waves was looking toward Web 3.0 when creating its Ride language because one of the most integral features is that it makes users and their data the most important part, everything else revolves around the user.
This type of thinking was prominent in the way they created their language, Ride, and the easiest way to see this is by directly comparing it to the current most popular dApp platform Ethereum’s language Solidity.
Ethereum is, without a doubt, the current industry leader when it comes to dApps, but that doesn’t necessarily mean that their approach of creating dApps is the most efficient. With Solidity, developers are given relative free reign when it comes to creating their dApps, which leads to the necessity of overall standards they have to fulfill. If the market was left to self regulate there would be little to no standard, and this would inevitably lead to a lack of cohesion between different dApps and the underlying protocols.
This is a tricky question, since it will always be up to the individual developers when it comes to language preferences. From an outside, objective perspective, Waves offers Ride with cheaper, easy-to-use, and predictable coding building blocks that allow for greater customization within pre-established boundaries.
Ethereum with its Solidity is still a great option considering the plans it has for the future (switching to PoS, possibly decreasing gas costs through sharding, and more), but it is currently falling behind its competitors. It’s apparent that Ethereum’s standards are one of their main strengths but also their greatest weakness, as these standards represent both Solidity’s coding freedom but also its inherent flaws and restrictions.
Ride has a chance to help progress Web 3.0 further than Solidity since it is creating an environment where no matter what the programmer creates (within the Ride language), it is automatically compliant and synergetic with the other dApps on Waves. Think back on that room of toys we discussed earlier: Ride is like playing with one specific toy, like Legos. All Legos are designed to fit, connect, and build upon one another automatically; it is their core design. So while Solidity is a toy box filled with tons of mismatching toys, their only guiding factor is that they are all being played with by the same child.
Ethereum and Solidity have certainly helped us get to where we are on the path toward Web 3.0, but it may be time for languages like Ride and Move to take over so we can create easily programmable, automatically synergistic, efficient code to move decentralized technology forward.