Blockchain Primitives and their Advantages for Web 3.0 Development

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.

Protocols: What and Why

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. 

Source: techspot.com

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.

Consolidating everything with DLT primitives

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.

Source: usv.com

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:

• Transfer Transactions – Initiated when an account needs to send or receive data on a blockchain. These are straightforward and consist of verifying signatures, amounts, and recipients of the transaction.
• Data Transactions – A transaction that writes data to an account data storage. Each data transaction has a data array that contains data to be written.
• Issue Transactions – A transaction that issues token.
• MassTransfer – Allows for a transfer transaction to send to multiple recipients.
  Issue: denotes a specific time and trigger event for a special data instance.
• Exchange – Exchanging one cryptocurrency for another without the participation of any third parties.
• SetScript – A transaction that attached a specific dApp script or account script to a specified account.
• NFTs – Or non-fungible token, is the tokenization of various digital and physical assets into a unique, verifiable form. These tokens, unlike a standard cryptocurrency, are typically not swapped for another in a 1-to-1 trade as each one has a special identifier.
• Sponsored Transactions – Allows a transaction to run using funds in escrow to prevent the user from having to pay fees.
• InvokeScript Transactions – A transaction that invokes the callable function on a dApp.

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.

Source: xkcd.com

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...

A different approach

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.

Waves vs. Ethereum: Framework vs. Standards

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.

Benefits for development

• Ethereum: Development in Solidity is guided by overarching standards, the most common of which being ERC-20. These standards act as rough guidelines for developers who want their dApps to interact with other dApps, companies, and the like. Aside from these standards there is no requirement for developers to adhere to any programming conditions, which leads to a certain Wild West mentality in the Ethereum dApp world.
• Waves: Development in Ride is guided by blockchain primitives designed as building blocks, which eliminates the need for standards. By creating these easy-to-use building blocks, Ride has made their developmental environment far more intuitive since developers don’t need to worry about which standard they need to follow, or if their dApp will work with other specific dApps in the future. These building blocks inherently allow for greater customization since anything built with them is automatically compliant, and incorporating self-explanatory, simple code only increases the ease of use.

Evaluating their network

• Ethereum: The benefits for the network in Ethereum are limited, but it holds onto market popularity since it has first-to-market advantage. Ethereum relies on gas (which fluctuates) to run its dApps, and since there are no simple building blocks to use when it comes to developing dApps, the programs themselves can become unpredictable both in function and in gas price. Take, for example, the popular Ethereum dApp CryptoKitties. To list a kitty, a user pays a gas fee associated with transferring their cat (ERC-721 token). For another user to buy this kitty, they have to send a buy transaction equal to the listing price (ERC-20 transfer), pay the gas, and then the ERC-721 transfer fee again. The second transaction requires two token transfers at once, which is more expensive. Also, users have to take into account the minimum and maximum gas cost per transfer. The minimum is 21,000 gas, the maximum varies (a block gas limit is roughly 8 million), so even if you set your gas limit very high but the transaction is still pending when it reaches your limit, your gas is gone. In addition, Ethereum’s chain relies on PoW mining, which is arguably one of the most wasteful consensus protocols on the market; but luckily they have plans to shift to PoS in the future.

Source: actionnetwork.com

• Waves: Since Ride uses building block code, developers who use the language can easily predict how complex their Waves-based dApps are. By using this complexity prediction, the cost of running apps is extremely predictable and there is no need to pay for gas in the hopes that you’ve given your dApp enough “fuel” to run. Thanks to this predictable fee system, developers will never run into a case of paying for too little gas and having their dApp rejected while simultaneously being forced to pay for more gas to get it to run. To make things even more simple, Ride doesn’t allow for failed transactions on their network unless a user attempts to pay the fee for a job that hasn’t been done yet. Since Ride never rejects a contract due to underpaid gas fees, the network is easier to use overall since they don’t have to learn nearly as much jargon to get started.

So what’s better?

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.

Souce: dilbert.com

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.