You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/blockchain-development-tutorials/cadence/getting-started/index.md
+14-2Lines changed: 14 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,6 +21,18 @@ keywords:
21
21
22
22
The Cadence is designed for the next generation of apps, games, and digital assets. This comprehensive tutorial series will guide you from setting up your development environment to deploying production-ready applications on Flow's mainnet while a complete Counter application that demonstrates all essential Flow development patterns.
After completing these tutorials, you'll be equipped with the fundamental skills needed for Flow development. Consider exploring our other tutorial series to expand your blockchain development expertise:
74
86
75
87
-[Cross-VM Apps] - Build applications that integrate Flow EVM and Cadence
76
-
-[Native VRF] - Implement verifiable random functions in your applications
88
+
-[Native VRF] - Implement verifiable random functions in your applications
77
89
-[Token Launch] - Create and launch tokens on Flow
78
90
79
91
<!-- Relative links -->
@@ -84,4 +96,4 @@ After completing these tutorials, you'll be equipped with the fundamental skills
One of the most under-discussed benefits of decentralization is **equitable access**. Ideally, the value and quality-of-service you receive from a decentralized platform should not depend on your identity, computing power, or personal connections. However, **Maximal Extractable Value (MEV)** poses a significant threat to this principle.
28
+
## The Hidden Cost of MEV in Decentralized Systems
19
29
20
-
MEV allows block producers to manipulate transaction ordering for profit—often at the direct expense of users. The ability to front-run, back-run, or sandwich transactions can extract value from ordinary users, reinforcing inequalities rather than eliminating them. In most blockchain networks, MEV is not just an unfortunate side effect; it is structurally embedded in how transactions are processed.
30
+
One of the most under-discussed benefits of decentralization is **equitable access**. Ideally, the value and quality-of-service you receive from a decentralized platform should not depend on your identity, computing power, or personal connections. However, **Maximal Extractable Value (MEV)** poses a significant threat to this principle.
21
31
22
-
## Why MEV Persists on Most Blockchains
32
+
MEV allows block producers to manipulate transaction ordering for profit—often at the direct expense of users. The ability to front-run, back-run, or sandwich transactions can extract value from ordinary users, reinforcing inequalities rather than eliminating them. In most blockchain networks, MEV is not just an unfortunate side effect; it is structurally embedded in how transactions are processed.
23
33
24
-
MEV is difficult to prevent on most blockchains because **each block has a single builder**. This builder must have:
34
+
## Why MEV Persists on Most Blockchains
25
35
26
-
- A full copy of the blockchain state
27
-
- The ability to simulate transactions before they are finalized
28
-
- Absolute control over transaction selection and ordering
36
+
MEV is difficult to prevent on most blockchains because **each block has a single builder**. This builder must have:
29
37
30
-
In practice, this means that **the entity responsible for adding your transaction to the blockchain can first simulate it to identify profit opportunities**. They can test hundreds or thousands of ways to rearrange transactions, inserting their own to extract MEV—often at **your** expense.
38
+
- A full copy of the blockchain state
39
+
- The ability to simulate transactions before they are finalized
40
+
- Absolute control over transaction selection and ordering
31
41
32
-
For example, if a block builder can earn $10 by sandwiching your transaction, it means **you** likely lose $10 in value. This is functionally theft, and the worst part? If your transaction is airtight and offers no MEV opportunities, the block builder has no obligation to include it at all. Pay the toll, or get locked out.
42
+
In practice, this means that **the entity responsible for adding your transaction to the blockchain can first simulate it to identify profit opportunities**. They can test hundreds or thousands of ways to rearrange transactions, inserting their own to extract MEV—often at **your** expense.
43
+
44
+
For example, if a block builder can earn $10 by sandwiching your transaction, it means **you** likely lose $10 in value. This is functionally theft, and the worst part? If your transaction is airtight and offers no MEV opportunities, the block builder has no obligation to include it at all. Pay the toll, or get locked out.
33
45
34
46
## How Flow Accomplishes MEV Resilience
35
47
36
-
Unlike many blockchains, **Flow was designed from the ground up to minimize MEV** through a unique multi-role architecture. Flow introduces key design choices that break the typical MEV-enabling structure:
48
+
Unlike many blockchains, **Flow was designed from the ground up to minimize MEV** through a unique multi-role architecture. Flow introduces key design choices that break the typical MEV-enabling structure:
49
+
50
+
### 1. **Separating Transaction Selection from Execution**
51
+
52
+
On Flow, **Collection Nodes** select transactions, but they do not have access to the execution state or computing power to simulate them. Meanwhile, **Execution Nodes** run transactions but cannot choose or reorder them.
53
+
54
+
This separation significantly reduces the ability of block builders to test transactions before execution. Even if an attacker controls both a Collection Node and an Execution Node, they cannot easily extract MEV.
37
55
38
-
### 1. **Separating Transaction Selection from Execution**
39
-
On Flow, **Collection Nodes** select transactions, but they do not have access to the execution state or computing power to simulate them. Meanwhile, **Execution Nodes** run transactions but cannot choose or reorder them.
56
+
### 2. **Separating Transaction Ordering from Execution**
40
57
41
-
This separation significantly reduces the ability of block builders to test transactions before execution. Even if an attacker controls both a Collection Node and an Execution Node, they cannot easily extract MEV.
58
+
Flow further decentralizes control by introducing **Consensus Nodes** that determine transaction order. These nodes are separate from both Collection Nodes and Execution Nodes.
42
59
43
-
### 2. **Separating Transaction Ordering from Execution**
44
-
Flow further decentralizes control by introducing **Consensus Nodes** that determine transaction order. These nodes are separate from both Collection Nodes and Execution Nodes.
60
+
For an attacker to perform MEV, they would need to:
45
61
46
-
For an attacker to perform MEV, they would need to:
47
-
- Control a **Collection Node** to insert a transaction
48
-
- Control a **Consensus Node** to place it in the desired order
49
-
- Have execution state access to predict its effects
62
+
- Control a **Collection Node** to insert a transaction
63
+
- Control a **Consensus Node** to place it in the desired order
64
+
- Have execution state access to predict its effects
50
65
51
-
This makes it vastly more difficult to extract MEV compared to traditional blockchains, where a single entity often controls all three functions.
66
+
This makes it vastly more difficult to extract MEV compared to traditional blockchains, where a single entity often controls all three functions.
67
+
68
+
### 3. **Strict Transaction Execution Rules**
52
69
53
-
### 3. **Strict Transaction Execution Rules**
54
70
Execution Nodes on Flow have a **simple, enforceable rule**:
55
-
They **must** execute transactions exactly as ordered by Consensus Nodes—or they get slashed.
71
+
They **must** execute transactions exactly as ordered by Consensus Nodes—or they get slashed.
72
+
73
+
Unlike traditional blockchains, where the same party both orders and executes transactions, Flow ensures that Execution Nodes cannot manipulate transaction order for profit.
74
+
75
+
### 4. **Parallel Processing for Extra MEV Resistance**
56
76
57
-
Unlike traditional blockchains, where the same party both orders and executes transactions, Flow ensures that Execution Nodes cannot manipulate transaction order for profit.
77
+
Flow’s unique **pipelined execution model** adds another layer of complexity for potential attackers.
58
78
59
-
### 4. **Parallel Processing for Extra MEV Resistance**
60
-
Flow’s unique **pipelined execution model** adds another layer of complexity for potential attackers.
79
+
While one block is being executed, the next block is undergoing consensus, and a third block is still collecting transactions. This means that **to front-run or sandwich attack on Flow, an attacker must successfully predict the outcome of at least two unexecuted blocks—one of which hasn’t even been built yet**.
61
80
62
-
While one block is being executed, the next block is undergoing consensus, and a third block is still collecting transactions. This means that **to front-run or sandwich attack on Flow, an attacker must successfully predict the outcome of at least two unexecuted blocks—one of which hasn’t even been built yet**.
81
+
Even with significant resources, this makes profitable MEV attacks incredibly difficult.
63
82
64
-
Even with significant resources, this makes profitable MEV attacks incredibly difficult.
83
+
## The End Result: A Fairer Blockchain
65
84
66
-
## The End Result: A Fairer Blockchain
85
+
Flow’s architecture ensures that:
67
86
68
-
Flow’s architecture ensures that:
69
-
- The nodes selecting transactions **don’t know** their order
70
-
- The nodes ordering transactions **don’t know** the blockchain state
71
-
- The nodes executing transactions **can’t** modify the order
87
+
- The nodes selecting transactions **don’t know** their order
88
+
- The nodes ordering transactions **don’t know** the blockchain state
89
+
- The nodes executing transactions **can’t** modify the order
72
90
73
-
By **intentionally separating powers**, Flow eliminates MEV at its root rather than merely mitigating its effects.
91
+
By **intentionally separating powers**, Flow eliminates MEV at its root rather than merely mitigating its effects.
74
92
75
93
This level of protection against MEV is not an afterthought—it has been a fundamental design goal of Flow since day one. If equitable access matters, **why settle for anything less?**
To satisfy the design goals and thanks to the extensibility properties of the Cadence runtime, Flow EVM is designed as a higher-level environment incorporated as a smart contract deployed to Cadence. This smart contract is not owned by anyone and has its own storage space, allows Cadence to query, and is updated through EVM transactions. EVM transactions can be wrapped inside Cadence transactions and passed to the EVM contract for execution. The artifacts of EVM transaction execution (e.g. receipts and logs) are emitted as special Cadence events (TransactionExecuted, BlockExecuted) and available to the upstream process (Flow transaction) to enable atomic operations.
Much of the protocol design is based on lessons learned from building Web3 applications while working at [Dapper Labs], particularly [CryptoKitties] — the first onchain game to reach [widespread popularity]. The game went viral, then [struggled under its own success] when it caused so much traffic that the Ethereum network itself was overwhelmed by the load.
42
54
43
55
The design of Flow was guided by the need to alleviate this burden while creating the best experience possible for both developers and users. The blockchain network of the future must be able to handle millions of users while upholding the key pillars of decentralization:
0 commit comments