Tweet

Simplify DeFi 📘

Mar 19 • 31 tweets • 12 min read

EVM L1/L2s WILL NEVER be able to handle the demands of Traditional Finance.

It's like upgrading a 1990 Ford Taurus to compete in a Formula 1 race.

This is how #Radix sees it. Their solution?

Create a L1 that's RADICALLY different and solves the Blockchain Trilemma.

Mega🧵👇

1.) Problems with current EVM L1/L2s:

❌NOT user-friendly.

❌Developers waste too much time rewriting/testing the same logic. Mistakes = Exploits.

❌Improvements in L1/L2s will sacrifice scalability, security, or decentralization.

❌Smart Contract architecture isn't good.

2.) Their Solution?

✅L1, POS, BFT, that SPECIALIZES in Cross-Shard data, execution, & consensus.

✅FAST (1M+ TPS), unlimited scaling, atomic composability, decentralized, & secure.

✅Built for an easy user & developer experience.

Let's simplify #Radix (Xi'an Release -2024)👇

3.) Key parts of #Radix we'll be covering [Xi'an Release - 2024]

🤳Amazing user experience. Way better than Metamask.

🏎️ Radix Engine = Processes transactions. It's like a video-game physics engine, but for DeFi.

🗳️ Cerberus = Consensus

💻 Shardspace (Shards & Data Storage)

4.) Problems with Metamask wallets (On EVM L1s/L2s):

🙅‍♂️ People don't like using it.

🔢 Transactions are unreadable.

😭 Can lose seed phrase.

🔎 Hard to see the true value of your portfolio.

📉 Slippage can impact you greatly.

➕etc.

5a.) Improvements - Radix Wallets

📜Transactions are easy to read.

⚖️You can specify the minimum amount of tokens you wish to receive. Too much slippage? The transaction won't happen.

📂Easy to see how much your portfolio is worth. (Including LPs)

5b.) Improvements - Radix Wallets

🔑Easy to recover account if phone gets lost/stolen.

👨‍💻Can create different accounts.

🎟️Easy to buy NFTs and even use in real life. Example: Your basketball ticket is a NFT. Pull it up on your wallet and get a discounted beer at a nearby bar.

6a.) EVM & Tokens

On #ETH, you're not actually transferring tokens between wallets.

Rather, a Smart Contract exists for that specific token. It holds a list containing EVERYONE who owns it.

When "transferring" tokens, the smart contract is changing its own records.

6b.) EVM & Tokens

The way how tokens are implemented on Ethereum can make Smart Contracts complicated.

For dAPPs, developers connect multiple smart contracts together. They need to make sure it is safe. If not, funds can get stolen.

Diagram of how a "simple swap" on ETH works:

6c.) EVM & Tokens

If you want create a token on Ethereum, you're pretty much starting with a blank drawing.

You're going to have to rewrite code/features that are common for most tokens.

A LOT of time will also go into testing and making sure your code isn't exploitable.

7a.) Radix Engine

Video-games USED to require developers to write complex code to make the character move, jump, etc.

However, the code could be reused.

Thanks to "Physics Engines" (Ex: Unreal Engine), developers are able to create games faster, easier, and with less bugs.

7b.) Radix Engine

The Radix Engine is Radix's EVM layer.

Just as the physics engines save video-game developers time, so does the Radix Engine.

It is designed to make creating tokens, accounts, asset logic, etc., extremely easy.

This greatly reduces time, testing, & EXPLOITS.

8a.) Scrypto

The programming language used to write smart contracts is Scrypto. This is based off Rust.

It's designed to be EXTREMELY easy to write in.

Also, it's an ASSET-ORIENTED language.

Developers don't have to constantly rewrite token logic in their smart contracts.

8b.) Scrypto

Smart Contracts = "Components" & "Blueprints" on Radix.

Blueprint = Template. Has common code that will be shared for every "Component" it creates.

Component = Created from the template. Has the code given from the template. It can be modified.

8c.) Scrypto

[Example]

Blueprint = A metal cookie cutter.

Component = The cookie you just created from the cookie cutter. You can still modify the cookie. Add chocolate chips to some, M&M's to others, etc.

Note: Developers can earn royalties off their blueprints.

9.) Cerberus (Consensus)

- There are 3 rounds of voting to confirm a transaction.

- Cerberus is heavily optimized to support cross-sharding consensus. (EVM L1s/L2s aren't)

- This allows Radix to handle an insane amount of transactions. It makes it fast, decentralized, & safe.

10a.) Sharding

Before talking about the power of cross-sharding, some key concepts about sharding:

Shard = A location where data can be permanently stored. It is handled by a group of nodes.

- Atomic Composability = Either the whole transaction SUCCEEDS or FAILS.

10b.) Sharding

- Problem for EVM L1s/L2s: When data is needed from two different shards (cross-sharding)

- If a portion in the transaction fails, it's a pain to undo everything on each shard.

- Allow multiple transactions to process at the same time if their data is unrelated!

11.) Cross-Sharding

It's difficult to maintain atomic composability with Cross-Sharding.

If a transaction fails on one shard but not the other, it slows down the system.

Radix solved this issue with how they validate transactions and configured their shards (Shardspace).

12a.) Shardspace

There's practically an unlimited number of shards in the shardspace (2^256).

Every confirmed transaction fills up a shard PERMANENTLY. (It's how Radix stores the changes made to the ledger)

12b.) Shardspace

Won't Radix eventually run out of shards?

No, the shards will never run out.

2^256 is such a big number, it can handle MILLIONS of transactions per second for MILLIONS of years.

(The amount of shards after that time would still be extremely, extremely small.)

13a.) Shards on Radix.

- A shard can be:

i.) be empty
ii.) have the latest data (open)
iii.) or contain old data and be sealed off (closed)

- Substate = A change to the ledger. This gets stored in the shard. (There are "Bring Up" & "Shut Down" Substates)

13b.) Shards on Radix.

- "Closed" shards have old data stored in it. It can never be used again. They link to the next shard where its data got updated.

- "Closed" shards create a trail, like a blockchain.

- "Open" shards have the latest data. It can be updated.

14.) Nodes & Validator Sets

Nodes = Computers that validate the transactions on the shards.

Nodes are assigned to a range of shards.

Validator Sets = Group of nodes assigned to the same shard. They all have to vote and come to a consensus whether the transactions are valid.

15a.) Atomic Composability & Braiding

- When a transaction comes in, it is going to involve TWO or more shards.

- If the nodes validating each modified shard agree, commit it! Else, discard the transaction.

- Radix's system does this extremely efficiently via "braiding".

15b.) Atomic Composability & Braiding

- Braiding = All Shards involved vote multiple times. If anything is not good, quickly fail the WHOLE transaction.

- 3 rounds of voting are recorded, hashed, & linked between each shard.

Here's a glimpse as to how it's recorded: 👇

16.) Simple Example

Imagine Shard World:

Each city can be empty or have ONE restaurant.

A restaurant can only move to another city if BOTH city councils agree.

Once relocated, the old restaurant is "CLOSED". It can never be used again. A sign says where it moved to.

17.) Advanced Example [Bonus Content]

We can use our Simple Example and push it MUCH further.

✅What if multiple restaurants want to merge into one?
✅What if the new restaurant moves again?
✅How do these city council members (nodes) operate?

See attached images 👇

18.) Unlimited Scalability & Transactions Per Second (Over 1 Million)

With the Shardspace and Cross-Sharding being heavily optimized, this allows for unlimited linear scalability and speed.

Simply continue to add more nodes. It'll be able to handle more transactions easily.