-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathcrypto-from-zero.html
More file actions
323 lines (309 loc) · 20.4 KB
/
Copy pathcrypto-from-zero.html
File metadata and controls
323 lines (309 loc) · 20.4 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Crypto From Zero | Kaspa Explained</title>
<meta name="description" content="Crypto from zero: why digital ownership is hard, why records need rules, why keys, transactions, blocks, consensus, mining, staking, tokens, and tradeoffs exist.">
<meta name="robots" content="index,follow,max-snippet:-1,max-image-preview:large">
<link rel="canonical" href="https://kaspaexplained.com/crypto-from-zero">
<link rel="icon" href="kaspa-favicon.svg?v=20260512-real-k" type="image/svg+xml">
<link rel="icon" href="favicon.svg?v=20260512-k4" type="image/svg+xml">
<link rel="icon" href="favicon.ico" sizes="any">
<link rel="icon" href="favicon.png" type="image/png">
<link rel="apple-touch-icon" href="apple-touch-icon.png">
<link rel="manifest" href="site.webmanifest">
<meta name="application-name" content="Kaspa Explained">
<meta name="apple-mobile-web-app-title" content="Kaspa Explained">
<meta name="theme-color" content="#000000">
<meta property="og:title" content="Crypto From Zero | Kaspa Explained">
<meta property="og:description" content="Crypto from zero: why digital ownership is hard, why records need rules, why keys, transactions, blocks, consensus, mining, staking, tokens, and tradeoffs exist.">
<meta property="og:type" content="article">
<meta property="og:url" content="https://kaspaexplained.com/crypto-from-zero">
<meta property="og:image" content="https://kaspaexplained.com/og-kaspa-explained-20260514.png?v=20260514-logo-clearance">
<meta property="og:image:type" content="image/png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Kaspa Explained - proof-of-work blockDAG guide">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Crypto From Zero | Kaspa Explained">
<meta name="twitter:description" content="Crypto from zero: why digital ownership is hard, why records need rules, why keys, transactions, blocks, consensus, mining, staking, tokens, and tradeoffs exist.">
<meta name="twitter:image" content="https://kaspaexplained.com/og-kaspa-explained-20260514.png?v=20260514-logo-clearance">
<meta name="dateModified" content="2026-07-08">
<link rel="stylesheet" href="styles.css?v=20260711-table-wrap-fix">
<script defer src="nav.js?v=20260708-dark-default"></script>
</head>
<body>
<a class="skip-link" href="#top">Skip to content</a>
<header class="site-header">
<nav class="nav" aria-label="Primary">
<a class="brand" href="/" aria-label="Kaspa Explained home">
<span class="brand-mark" aria-hidden="true"></span>
Kaspa Explained
</a>
<button class="nav-menu-button" type="button" aria-expanded="false" aria-controls="primary-links">Menu</button>
<div id="primary-links" class="nav-links">
<a href="/what-is-kaspa">What is Kaspa</a>
<a href="/status">Live now</a>
<a href="/kaspa-claims-checker">Check claims</a>
<a href="/skeptical-case">Risks</a>
<a href="/build-on-kaspa">Build</a>
<a href="/sources">Sources</a>
</div>
<button class="theme-toggle" type="button" aria-label="Switch theme">Light</button>
<a class="nav-cta" href="/toccata-status">Toccata status</a>
</nav>
</header>
<main id="top" tabindex="-1" class="knowledge-page">
<section class="knowledge-hero section">
<p class="eyebrow">Crypto from zero</p>
<h1>Crypto starts with shared records</h1>
<p class="lead">Your bank balance, your concert ticket, your game items: all of them are records. The hard question was never storing the record, it's who can change it, who checks the change, and why everyone else has to accept it.</p>
<blockquote>Crypto keeps one shared digital record without one trusted operator. Remove the operator and you inherit their old job: keys, consensus, incentives, markets, and group action all have to be rebuilt from scratch.</blockquote>
</section>
<section class="section">
<p class="eyebrow">The ladder</p>
<h2>From zero to Kaspa</h2>
<div class="timeline">
<article><span>1</span><h3><a href="#records">Records</a></h3><p>Who owns what? Who paid whom? Which update happened first?</p></article>
<article><span>2</span><h3><a href="#keys">Keys</a></h3><p>A private key lets a user authorize updates without asking a platform login server.</p></article>
<article><span>3</span><h3><a href="#transactions">Transactions</a></h3><p>A transaction is a signed instruction asking the shared record to change.</p></article>
<article><span>4</span><h3><a href="#transactions">Blocks</a></h3><p>A block packages valid updates into a proposed piece of shared history.</p></article>
<article><span>5</span><h3><a href="#consensus">Consensus</a></h3><p>Independent computers need rules for which history counts when updates conflict.</p></article>
<article><span>6</span><h3><a href="#incentives">Incentives</a></h3><p>Unknown operators need reasons to follow rules and costs for attacking them.</p></article>
<article><span>7</span><h3><a href="#tokens">Markets</a></h3><p>Tokens trade because users, miners, validators, investors, and apps need entry and exit.</p></article>
<article><span>8</span><h3><a href="#kaspa-appears">Kaspa</a></h3><p>Kaspa keeps PoW and UTXO design, then uses a blockDAG to reduce the single-chain bottleneck.</p></article>
</div>
</section>
<section id="records" class="section">
<p class="eyebrow">Layer 0</p>
<h2>Why digital ownership is hard</h2>
<div class="fit-grid">
<article class="section">
<h3>Physical cash has location</h3>
<p>Hand someone a banknote and you no longer hold it. The physical object cannot sit in two wallets at once: scarcity is a property of matter, free of charge.</p>
</article>
<article class="section">
<h3>Digital data copies for free</h3>
<p>Copy a file, edit a database row, screenshot an image: nothing stops you. Scarcity doesn't survive the jump to bits, so digital money has to manufacture it with rules instead of physics.</p>
</article>
</div>
<p class="fit-note"><strong>Summary:</strong> Coins never actually move anywhere. A valid transaction changes an accepted record, and that record is the whole asset.</p>
</section>
<section class="section">
<p class="eyebrow">Trusted operator</p>
<h2>Why a bank database is simpler</h2>
<p>Most systems solve the ownership problem with an operator. A bank, exchange, payment app, or platform runs the database and decides which updates count. One authority fixing mistakes, blocking fraud, reversing payments, and pushing upgrades is a cheaper design than the alternative, right up until you need something the authority won't give you.</p>
<div class="table-wrap">
<table class="reality-table">
<thead><tr><th>Operator model</th><th>What it gives you</th><th>What it can cost</th></tr></thead>
<tbody>
<tr><td>Bank or payment app</td><td>Customer support, reversals, fraud handling, legal recourse.</td><td>Account freezes, censorship, operating hours, jurisdiction limits, counterparty risk.</td></tr>
<tr><td>Exchange or platform</td><td>Fast internal balances and easy UX.</td><td>Custody risk, hidden liabilities, withdrawal risk, policy changes.</td></tr>
<tr><td>Public crypto network</td><td>Rules can be checked by independent participants.</td><td>More complexity, irreversible mistakes, public data, slower coordination.</td></tr>
</tbody>
</table>
</div>
</section>
<section id="keys" class="section">
<p class="eyebrow">Why cryptography</p>
<h2>Crypto needs proof without a login desk</h2>
<div class="reference-grid">
<article>
<h3>Private key</h3>
<p>The secret that controls spending authority. If someone steals yours, the network can't tell the thief from you: there is no ID check behind the math.</p>
</article>
<article>
<h3>Public key or address</h3>
<p>Lets anyone verify a signature is valid without ever seeing the private key that produced it.</p>
</article>
<article>
<h3>Signature</h3>
<p>Proof that the key holder authorized this specific transaction. It stands in for the username, password, and account admin a normal platform would use.</p>
</article>
<article>
<h3>Hash</h3>
<p>A fingerprint for data. Change one byte of the input and the fingerprint changes completely, which is what lets a block chain to its history and makes tampering visible.</p>
</article>
</div>
<p class="verified-note"><strong>What breaks without keys:</strong> the system falls back on a central login authority or an identity registry to decide who can move a balance.</p>
</section>
<section id="transactions" class="section">
<p class="eyebrow">Transactions and blocks</p>
<h2>Why transactions and blocks exist</h2>
<div class="fit-grid">
<article class="section">
<h3>Transaction</h3>
<p>A signed instruction: spend this value, create that new value, pay this fee. Every field in it exists so a stranger's node can check it without asking the sender anything else.</p>
<p><strong>Why it exists:</strong> the network needs one precise, self-contained object a stranger's node can validate alone.</p>
</article>
<article class="section">
<h3>Block</h3>
<p>A batch of valid transactions linked to prior history. Nodes either accept the whole batch under the protocol's rules or reject it. There is no partial credit.</p>
<p><strong>Why it exists:</strong> the network needs a shared unit of history that a majority can agree happened.</p>
</article>
</div>
</section>
<section id="consensus" class="section">
<p class="eyebrow">Consensus</p>
<h2>Why records need agreement</h2>
<p>A record is only worth something if strangers agree it's the record. Show Bob one ledger and Carol another and you've just spent the same coin twice. Consensus exists because thousands of independent computers see network messages arrive in different orders, and they still have to converge on one shared state anyway.</p>
<div class="check-grid">
<span>Which transaction came first?</span>
<span>Which block counts?</span>
<span>Was the same value spent twice?</span>
<span>Did a miner or validator follow the rules?</span>
<span>Can history be rewritten cheaply?</span>
<span>Can users verify the supply?</span>
</div>
</section>
<section id="security-cost" class="section">
<p class="eyebrow">Security</p>
<h2>Security means the record resists lies</h2>
<div class="table-wrap">
<table class="reality-table">
<thead><tr><th>Attack</th><th>Plain meaning</th><th>Why users care</th></tr></thead>
<tbody>
<tr><td>Theft</td><td>Spend value without the rightful key holder's consent.</td><td>Ownership is meaningless if signatures can be forged or keys are stolen.</td></tr>
<tr><td>Double-spend</td><td>Try to spend the same value in two conflicting ways.</td><td>Recipients need to know which payment counts.</td></tr>
<tr><td>Rewrite</td><td>Replace accepted history with a different history.</td><td>Settlement needs confidence that old payments stay settled.</td></tr>
<tr><td>Censorship</td><td>Prevent valid transactions from entering history.</td><td>Open access fails if a control point can cheaply block users.</td></tr>
<tr><td>Hidden inflation</td><td>Create value outside the rules.</td><td>Supply rules work only if users can independently reject invalid supply.</td></tr>
</tbody>
</table>
</div>
</section>
<section id="incentives" class="section">
<p class="eyebrow">Mining and staking</p>
<h2>Consensus has to cost something</h2>
<div class="fit-grid">
<article class="section">
<h3>Proof of Work</h3>
<p>PoW prices out fake history with a cost outside the system: hardware, electricity, time. Miners propose blocks and get paid only if that work sticks in accepted history.</p>
<p><strong>Tradeoff:</strong> energy use, ASICs, mining pools, industrial concentration pressure.</p>
</article>
<article class="section">
<h3>Proof of Stake</h3>
<p>PoS prices out fake history with a cost inside the system: validators post the native asset as collateral and can lose it for provable bad behavior, depending on the design.</p>
<p><strong>Tradeoff:</strong> wealth concentration, delegation, staking-provider power, harder social-recovery questions when things go wrong.</p>
</article>
</div>
</section>
<section id="tokens" class="section">
<p class="eyebrow">Tokens</p>
<h2>Why public networks often use tokens</h2>
<p>A permissionless network needs some internal economic unit to price fees, pay rewards, resist spam, and fund its own security. Wanting a token is not the same as needing one.</p>
<div class="reference-grid">
<article><h3>Object tracked</h3><p>The ledger records ownership of the asset itself.</p></article>
<article><h3>Fee asset</h3><p>Users pay for scarce block space and avoid free spam.</p></article>
<article><h3>Security reward</h3><p>Miners or validators are paid to operate and defend the system.</p></article>
<article><h3>Market entry</h3><p>Open markets let users, miners, validators, apps, and investors enter or exit without one issuer approving every participant.</p></article>
</div>
<p class="fit-note"><strong>Simple check:</strong> most tokens don't need to exist. Ask what this one does that BTC, ETH, USDC, or a plain database doesn't already do.</p>
</section>
<section class="section">
<p class="eyebrow">UTXO and account models</p>
<h2>Two ways to track state</h2>
<div class="fit-grid">
<article class="section">
<h3>Account model</h3>
<p>A balance table. Alice has 10, sends 3, and now Alice has 7 while Bob has 3. Intuitive, and the default for smart-contract platforms, until two transactions touch the same shared balance at once and ordering starts to matter.</p>
</article>
<article class="section">
<h3>UTXO model</h3>
<p>More like cash notes than a ledger. Alice spends a 10-coin output, Bob receives a 3-coin output, Alice receives a 7-coin change output, and the original 10-coin note is gone for good.</p>
</article>
</div>
<p>Kaspa uses a UTXO model, same as Bitcoin. That single choice shapes how validation works, how much can run in parallel, and what shape future programmability can even take.</p>
<div class="concept-diagram" role="img" aria-label="UTXO transaction spends one old output and creates recipient and change outputs">
<svg viewBox="0 0 760 230" aria-hidden="true">
<defs>
<marker id="arrowhead" markerWidth="10" markerHeight="7" refX="9" refY="3.5" orient="auto">
<polygon points="0 0, 10 3.5, 0 7"></polygon>
</marker>
</defs>
<rect class="diagram-box spent" x="32" y="70" width="150" height="90" rx="10"></rect>
<text class="diagram-title" x="107" y="106">Old UTXO</text>
<text class="diagram-text" x="107" y="132">10 KAS</text>
<path class="diagram-arrow" d="M190 115 H300"></path>
<rect class="diagram-box tx" x="308" y="58" width="144" height="114" rx="10"></rect>
<text class="diagram-title" x="380" y="105">Signed</text>
<text class="diagram-title" x="380" y="130">transaction</text>
<path class="diagram-arrow" d="M460 95 H575"></path>
<path class="diagram-arrow" d="M460 138 H575"></path>
<rect class="diagram-box live" x="585" y="50" width="140" height="70" rx="10"></rect>
<text class="diagram-title" x="655" y="82">Bob gets</text>
<text class="diagram-text" x="655" y="104">3 KAS</text>
<rect class="diagram-box live" x="585" y="136" width="140" height="70" rx="10"></rect>
<text class="diagram-title" x="655" y="168">Alice change</text>
<text class="diagram-text" x="655" y="190">7 KAS</text>
</svg>
<p><strong>How to read it:</strong> the old output is consumed once. New outputs carry the next spendable state.</p>
</div>
</section>
<section id="kaspa-appears" class="section">
<p class="eyebrow">Kaspa appears here</p>
<h2>Where Kaspa enters</h2>
<p>Bitcoin-style chains pick one block path at a time and throw away the rest. That's conservative and it works, but it caps how fast blocks can arrive: two honest miners who solve a block seconds apart start competing instead of both counting. Kaspa's bet is that a mined UTXO network can keep both blocks, order them with GHOSTDAG instead of discarding one, and get payments closer to real time without changing what PoW is securing.</p>
<div class="actions">
<a class="button primary" href="/why-kaspa-matters">Kaspa design case</a>
<a class="button" href="/where-kaspa-fits">Where Kaspa fits</a>
</div>
</section>
<section class="next-step section" aria-label="Suggested next step">
<p class="eyebrow">Next step</p>
<h2>Understand value and coin categories next</h2>
<p>Mechanics explain how a record changes hands. They don't explain why a token has a price, or why Bitcoin and Ethereum aren't competing for the same job.</p>
<div class="actions">
<a class="button primary" href="/why-crypto-has-value">Why crypto has value</a>
<a class="button" href="/why-are-there-so-many-coins">Open coin atlas</a>
</div>
</section>
<!-- related-links:start -->
<section class="section site-related" aria-labelledby="related-links-title">
<p class="eyebrow">Keep reading</p>
<h2 id="related-links-title">Next pages</h2>
<div class="site-related-grid">
<a href="/what-is-kaspa"><span>Previous</span><strong>What is Kaspa?</strong><p>What is Kaspa? KAS, Proof of Work, blockDAGs, GHOSTDAG, 10 BPS, and what's live on mainnet versus still roadmap.</p></a>
<a href="/why-crypto-has-value"><span>Next</span><strong>Why crypto has value</strong><p>Why cryptoassets have prices: token need, market cap, liquidity, security budget, speculation, launch design, open markets, and why price...</p></a>
<a href="/status"><span>Status</span><strong>Kaspa current status</strong><p>What is live, targeted, roadmap, and research on Kaspa right now, checked against mainnet, releases, and KIPs.</p></a>
</div>
</section>
<!-- related-links:end -->
</main>
<footer class="footer">
<div class="footer-grid">
<p><strong>Independent Kaspa explainer.</strong> Claims are labeled live, targeted, roadmap, research, unsupported, or wrong. Not investment advice.</p>
<nav class="footer-nav-groups" aria-label="Footer">
<div class="footer-link-group" aria-label="Learn">
<span>Learn</span>
<a href="/start-here">Start here</a>
<a href="/what-is-kaspa">Kaspa 101</a>
<a href="/overview">90-second overview</a>
<a href="/glossary">Glossary</a>
</div>
<div class="footer-link-group" aria-label="Verify">
<span>Verify</span>
<a href="/status">Status</a>
<a href="/kaspa-claims-checker">Claims checker</a>
<a href="/toccata-status">Toccata status</a>
<a href="/skeptical-case">Skeptical case</a>
<a href="/sources">Sources</a>
</div>
<div class="footer-link-group" aria-label="Build">
<span>Build</span>
<a href="/build-on-kaspa">Build on Kaspa</a>
<a href="/builder-guide">Builder guide</a>
<a href="/kaspa-app-ideas">App ideas</a>
</div>
<div class="footer-link-group" aria-label="Site">
<span>Site</span>
<a href="/search">Search</a>
<a href="/about">About</a>
<a href="/about#corrections">Corrections</a>
</div>
</nav>
</div>
</footer>
</body>
</html>