How a Game Engine for DeFi Could Facilitate Accelerated Development

0

[ad_1]

The beating heart of any decentralized application ecosystem, DApps, is its underlying technology stack. For Ethereum (ETH), these are its “Nakamoto” consensus, its Ethereum Virtual Machine (EVM) runtime environment, and its Solidity programming language. Together, these technologies have enabled smart contract developers to take decentralized finance (DeFi) from concept to reality.

For DeFi to take the next step – towards mainstream adoption – scalability is the technology requirement that gets the most attention. But an often overlooked but equally important aspect of Layer 1 platforms is their approach to developing smart contracts.

While Solidity and EVM are the core technologies that have allowed Ethereum to be the undisputed pioneer in DeFi, they are also the pioneers who make all the mistakes. Have you ever wondered why it feels like there is an endless series of DeFi hacks and exploits today? It’s the result of a programming approach that makes it incredibly difficult to securely manage tokens. Because when Ethereum was designed, DeFi didn’t exist.

But a solution is not easy. Major changes to Solidity and EVM are not possible as this would break the majority of DApps that have already been built. Therefore, new platforms have a real opportunity to learn and improve the developer experience – as the improved DApps these developers create could enable the next wave of DeFi adoption.

Why DeFi development is difficult on Ethereum

Whether it’s tokens for decentralized borrowing and lending, tokens for an NFT game or artwork, or tokens for a financial derivative, they’re central to virtually every use case. of DeFi and crypto.

However, the only token that the Ethereum platform natively understands is ETH. All other tokens, whether they fall under ERC-20, 721, 1155 or any other standard, only exist as variables (old regular numbers) inside each smart contract.

The Tether token – USDT –– is a list of accounts and associated balances in the USDT smart contract. The same goes for Shiba Inu (SHIB) and all other tokens built on Ethereum. This is why you cannot trade ETH on Uniswap (UNI), and, instead, you must, oddly, trade wrapped ETH (wETH), which is an ETH-backed ERC-20 token held in custody.

This poses problems. You cannot “send” tokens from one person to another because the tokens do not reside in a user’s wallet. They only live as a balance associated with an account inside each individual contract.

To exchange USDT for SHIB, a message is sent to debit your account in the USDT contract and credit your account in the SHIB contract. But the USDT debited from your account must go to another account in the USDT contract, and likewise, the SHIB credited to your account must come from another account in the SHIB contract.

With the burden of implementing a new token in every smart contract and for developers to ensure their contracts are safe in all possible scenarios, developers spend almost all of their time, up to 90%, on testing and validation. This hardly leaves them time to build what they really want: DeFi functionality.

With such a frustrating developer experience, is there a better way?

Tokens at the heart of DeFi development

DeFi is all about tokens. This means that tokens shouldn’t be an afterthought in the development experience – they should be front and center – at the very heart of the platform.

That’s why the right programming language can accelerate the development of not just a single platform, but an entire industry. An example of what is done is Baseda layer one protocol, which uses “asset-oriented” programming and introduces it with its Crypto programming language.

How it works? First, tokens are no longer defined in a smart contract, as with the list of accounts and balances described above. Instead, the tokens live in a separate layer, following the rules that the platform enforces. Just as the Bitcoin platform mandates that BTC cannot be double-spent, drained, or lost in one transaction, asset-oriented programming also ensures these same kinds of logical behaviors, but for every token created on the platform.

With these rules in place, tokens acquire the same properties that you would expect from a physical coin in your pocket. You can physically give it to someone else, but the platform ensures that the token cannot be in two places at once, nor can it disappear.

Given this physical behavior, DeFi developers can then create DeFi DApps as they would intuitively draw them on a whiteboard. Words like “take” and “put” in the programming language actually take and place tokens in places.

No more defining finance rules in every smart contract, from scratch, like with Solidity. With Radix, developers have all the tools they need to quickly create secure code, increasing their productivity.

Ultimately, whether developers flock to a new paradigm or prefer the old depends on a fine balance between the network effect of the old and the benefits of the new.

Learning a new approach to developing DeFi takes work. And that’s especially risky if the ecosystem you’re building for is starting from scratch, versus an ecosystem with thousands of DApps, mature developer communities, and millions of users.

But as we’ve seen in 2021, new layers can develop quickly. With the right execution, there’s a chance we could see a new upstart in town. One that might very well be able to galvanize a community of laser-focused developers on the mainstream adoption of DeFi.

Warning. Cointelegraph does not endorse any content or product on this page. Although we aim to provide you with all important information we may obtain, readers should do their own research before taking any action related to the company and take full responsibility for their decisions, and this article cannot no longer be considered as investment advice.

[ad_2]
Source link

Share.

Comments are closed.