kaspa-explained/crypto-from-zero.html at main · parker2017code/kaspa-explained · GitHub

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
<!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="#09090b">
  <meta property="og:title" content="Crypto From Zero | Kaspa Explained">
  <meta property="og:description" content="Why crypto needs records, keys, transactions, blocks, consensus, incentives, tokens, and tradeoffs before Kaspa is introduced.">
  <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="Why crypto needs records, keys, transactions, blocks, consensus, incentives, tokens, and tradeoffs before Kaspa is introduced.">
  <meta name="twitter:image" content="https://kaspaexplained.com/og-kaspa-explained-20260514.png?v=20260514-logo-clearance">
  <meta name="dateModified" content="2026-05-16">
  <link rel="stylesheet" href="styles.css?v=20260520-status-pill-wrap">
  <script defer src="nav.js?v=20260514-clean"></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="/start-here">Start</a>
        <a href="/overview">Overview</a>
        <a href="/kaspa-claims-checker">Check claims</a>
        <a href="/toccata-status">Toccata live?</a>
        <a href="/builder-guide">Build</a>
        <a href="/skeptical-case">Risks</a>
        <a href="/sources">Sources</a>
        <a href="/search">Search</a>
      </div>
      <button class="theme-toggle" type="button" aria-label="Switch theme">Light</button>
      <a class="nav-cta" href="/status">What is live?</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">Money, balances, tickets, game items, stablecoins, and crypto all depend on records. The hard question is who can update the record, who checks the update, and why everyone else should accept it.</p>
      <blockquote>Crypto keeps one shared digital record without one trusted operator. That creates new problems around keys, consensus, incentives, markets, and group action.</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="#security-cost">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>If Alice hands Bob a banknote, Alice no longer has that same banknote. The physical object cannot be in both wallets at once.</p>
        </article>
        <article class="section">
          <h3>Digital data copies easily.</h3>
          <p>A file can be copied. A database row can be edited. A screenshot can be duplicated. Digital money therefore needs rules that make one accepted ownership state hard to fake.</p>
        </article>
      </div>
      <p class="fit-note"><strong>Beginner line:</strong> Coins do not fly through the internet. A valid transaction changes an accepted record.</p>
    </section>

    <section class="section">
      <p class="eyebrow">Trusted operator</p>
      <h2>Why a bank database is simpler.</h2>
      <p>A normal system has an operator. A bank, exchange, payment app, game company, or platform runs the database and decides which updates count. This is efficient because one authority can fix mistakes, block fraud, reverse payments, close accounts, and coordinate upgrades.</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 it, the network cannot magically know they are not the owner.</p>
        </article>
        <article>
          <h3>Public key or address</h3>
          <p>A way for others to verify that a valid signature was produced without learning the private key.</p>
        </article>
        <article>
          <h3>Signature</h3>
          <p>Proof that the holder of the key authorized a transaction. This replaces usernames, passwords, and a central account admin at the protocol layer.</p>
        </article>
        <article>
          <h3>Hash</h3>
          <p>A fingerprint for data. Hashes let blocks link to prior history and make tampering detectable.</p>
        </article>
      </div>
      <p class="verified-note"><strong>What breaks without keys:</strong> the system needs a central login authority or real-world identity registry to decide who can update balances.</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 update request. It says, in effect: given the current rules, spend this value, create that new value, and pay this fee.</p>
          <p><strong>Why it exists:</strong> the network needs a precise object to validate.</p>
        </article>
        <article class="section">
          <h3>Block</h3>
          <p>A proposed batch of valid transactions linked to prior history. A block is a consensus object, not an ordinary network packet.</p>
          <p><strong>Why it exists:</strong> the network needs a shared unit of history to accept or reject.</p>
        </article>
      </div>
    </section>

    <section id="consensus" class="section">
      <p class="eyebrow">Consensus</p>
      <h2>Why records need agreement.</h2>
      <p>A record only matters if other people accept it. If Alice can show Bob one ledger and Carol another, Alice can attempt a double-spend. Consensus exists because independent computers see messages in different orders and still need one accepted state.</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 matter only if users can independently reject invalid supply.</td></tr>
          </tbody>
        </table>
      </div>
    </section>

    <section 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 makes fake history expensive through external cost: hardware, electricity, time, operations, and competition. Miners propose blocks and earn rewards if their work becomes part of accepted history.</p>
          <p><strong>Tradeoff:</strong> energy use, ASICs, mining pools, and industrial concentration pressure.</p>
        </article>
        <article class="section">
          <h3>Proof of Stake</h3>
          <p>PoS makes fake history expensive through internal collateral: validators lock the native asset and can lose rewards or stake for bad behavior, depending on the design.</p>
          <p><strong>Tradeoff:</strong> wealth concentration, delegation, staking-provider power, and more complex social recovery questions.</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 often needs an internal economic unit for value, fees, rewards, spam resistance, collateral, governance, or security budget. A project wanting a token is not enough.</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> many tokens do not need to exist. Ask what the token does that BTC, ETH, USDC, or a normal database cannot 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>Looks like a balance table. Alice has 10, sends 3, and now Alice has 7 while Bob has 3. This is intuitive and common for smart-contract platforms. Shared mutable state can become complex.</p>
        </article>
        <article class="section">
          <h3>UTXO model</h3>
          <p>Looks more like cash notes. Alice spends a 10-coin output, Bob receives a 3-coin output, and Alice receives a 7-coin change output. The old output becomes spent, not spendable again.</p>
        </article>
      </div>
      <p>Kaspa, like Bitcoin, uses a UTXO model. That matters for validation, parallelism potential, and the shape of future programmability.</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>UTXO intuition:</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 usually choose one block path at a time. That conservative design makes high block rates difficult because honest blocks found in parallel can conflict. Kaspa tests whether a mined UTXO network can include more parallel honest work, order it with GHOSTDAG, and make payments feel closer to real time.</p>
      <div class="actions">
        <a class="button primary" href="/why-kaspa-matters">Why Kaspa matters</a>
        <a class="button primary" href="/where-kaspa-fits">Where Kaspa fits</a>
        <a class="button" href="/status">What is live</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>After the mechanics, the next beginner gap is why tokens have prices and why major coins are not all trying to be the same thing.</p>
      <div class="actions">
        <a class="button primary" href="/why-crypto-has-value">Why crypto has value</a>
        <a class="button" href="/coin-atlas">Open coin atlas</a>
      </div>
    </section>
  </main>

  <footer class="footer">
    <div class="footer-grid">
      <p><strong>Independent resource.</strong> Kaspa-positive research guide, not investment advice.</p>
      <nav aria-label="Footer">
        <a href="/status">Status</a>
        <a href="/sources">Sources</a>
        <a href="/ai-guidance">Ask AI</a>
        <a href="/search">Search</a>
        <a href="/about">About</a>
        <a href="/claims-reference">Claims</a>
        <a href="https://github.com/parker2017code/kaspa-explained">GitHub</a>
      </nav>
    </div>
  </footer>
</body>
</html>