The Problem with Smart Contracts Today (part 1 of an X-part series)

Part 1: https://www.radixdlt.com/post/the-problem-with-smart-contracts-today

1) Intro: Brief history of "CryptoTechnology"

2009: Bitcoin - Single-purpose public, decentralized ledger (architecture: blockchain, dApp: currency)
2013: Ethereum - General-purpose p, d ledger (architecture: blockchain, dApps: programmable)

Interim: <Insert a smart contract platform of choice>
- General-purpose "scalable" p, d ledger (architecture: blockchain, DAG, ...)

\*A gold rush of sorts took/takes place to scale smart contract platforms [SCALABILITY]\*

2019: DeFi - The killer application of Decentralized Ledger Technology (DLT) becomes visible
2020: DeFi summer - The killer DLT-app thesis plays out:
- TVL in DeFi protocols swells from 1bn$ to 7bn$ in 90 days, still dwarfed by global finance: 111tn$

(Source 111tn$: https://www.pwc.com/gx/en/asset-management/asset-management-insights/assets/awm-revolution-full-report-final.pdf)

2) Point: The problem this blog post highlights is that the approach to smart contracts originating from Ethereum (2013) was not (!) designed with Decentralized Finance (DeFi) in mind

You can read in the linked article what the above exactly means

\*Furthermore, (most of) the projects that came behind ETH are tunnel visioned on [SCALABILITY]\*
But they (!) forgot about the prerequisite for scalability: [BUILDABILITY]

Why a prerequisite? => Scalability has a supply & demand side
[SUPPLY(scalability)]: How much traffic can the smart contract platform process per time unit?[DEMAND(scalability)]: How much traffic per time unit is being generated by devs & users?

=> How much scalability a SC platform can supply is (!) meaningless if there is no demand for it.
(Referring to global adoption, tx fees signal at the moment that there is more demand than supply)

TLDR;

If building smart contracts aren't "easy, safe, reusable, and composable."
Then there will be (!) no mass demand on a global scale...

Smart contracts as they are now being built do not satisfy these requirements
An alternative programming paradigm is required for this and is proposed by Radix (part 2)

Case study in the article as an illustration: DEX (Uniswap)

'Prove first the correct way of building and then scale it all up'

3) Key takeaways:

When not [EASY]: "The result is an extremely small community of experienced DeFi developers, a hugely inadequate hiring pool for entrepreneurs that limits what they can create, and DeFi dApps that are as elementary as possible to minimize the risk of expensive exploits."

When not [SAFE]: "The result is that developing virtually any production-ready dApp rapidly becomes a mass of unwieldy code that is extraordinarily difficult to analyze for safe asset management and authorization. The opportunities for exploitation are nearly impossible to avoid."

When not [REUSABLE]: "The result is that Ethereum is full of redundant code, standards are slow to emerge and adapt to needs, and dApps become ever more complex to build. This in turn further amplifies shortcomings of development ease and code safety."

Implications when [COMPOSABLE]: "As more and more dApps are composed together, development difficulty and opportunities for safety failures don’t just add up - they multiply"
+ "Even “scalable” network concepts that retain the possibility of composing dApps together do so by increasing the complexity for the developer."

Blog series, part 1: https://www.radixdlt.com/post/the-problem-with-smart-contracts-today

Postscriptum

PS. There is a preview event for the Alexandria release which will unveil:
* Radix’s “asset-oriented” Radix Engine
&
* Scrypto smart contract language

https://www.radixdlt.com/post/ape-radix-alexandria-preview-event

PPS. There recently was a Radix roundtable: https://www.youtube.com/watch?v=bLPLY70ywt0
Ideal to learn about the vision and the people behind it