Fossil SCM
All but rewrote the Cryptocurrency section of the new blockchain.md doc to clarify the sorts of frauds each system has to prevent so that we can draw clearer analogies.
Commit
154d848d2ecb500fc462006208989d1b9420388d66365f663bede3539e9c397e
Parent
95203913c0cf229…
1 file changed
+163
-109
+163
-109
| --- www/blockchain.md | ||
| +++ www/blockchain.md | ||
| @@ -25,11 +25,11 @@ | ||
| 25 | 25 | you traverse the Fossil repository from the tips of its [DAG] to the |
| 26 | 26 | root by following the parent hashes in each manifest, you will then have |
| 27 | 27 | a Merkle tree. Point-for-point, Fossil follows that definition. |
| 28 | 28 | |
| 29 | 29 | Every change in Fossil starts by adding one or more manifests to |
| 30 | -the repository. | |
| 30 | +the repository, extending this tree. | |
| 31 | 31 | |
| 32 | 32 | [bcwp]: https://en.wikipedia.org/wiki/Blockchain |
| 33 | 33 | [DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph |
| 34 | 34 | [SHA-1]: https://en.wikipedia.org/wiki/SHA-1 |
| 35 | 35 | [SHA-3]: https://en.wikipedia.org/wiki/SHA-3 |
| @@ -38,171 +38,224 @@ | ||
| 38 | 38 | |
| 39 | 39 | ## Cryptocurrency |
| 40 | 40 | |
| 41 | 41 | Because blockchain technology was first popularized as Bitcoin, many |
| 42 | 42 | people associate the term with cryptocurrency. Fossil has nothing to do |
| 43 | -with cryptocurrency, so a claim that “Fossil is a blockchain” may run up | |
| 44 | -against problems due to conflation with cryptocurrency. | |
| 43 | +with cryptocurrency, so a claim that “Fossil is a blockchain” may fail | |
| 44 | +to communicate the speaker’s concepts clearly due to conflation with | |
| 45 | +cryptocurrency. | |
| 45 | 46 | |
| 46 | 47 | Cryptocurrency has several features and requirements that Fossil doesn’t |
| 47 | 48 | provide, either because it doesn’t need them or because we haven’t |
| 48 | 49 | gotten around to creating the feature. Whether these are essential to |
| 49 | -the definition of “blockchain” and thus make Fossil “not a blockchain” | |
| 50 | +the definition of “blockchain” and thus disqualify Fossil as a blockchain | |
| 50 | 51 | is for you to decide. |
| 51 | 52 | |
| 52 | -1. **Signatures.** Blocks in a cryptocurrency have to be signed by the | |
| 53 | - *prior* owner of each block in order to transfer the money to the | |
| 54 | - new holder, else the new recipient could claim to have received any | |
| 55 | - amount of money they want by editing the face value of the currency | |
| 56 | - block. The chain of signatures also lets us verify that each block | |
| 57 | - is transferred only once, solving the double-spending problem. These | |
| 58 | - are both types of forgery, but they’re distinct sorts: changing a | |
| 59 | - US $20 bill to $100 is different from simply making more $20 bills | |
| 60 | - that look sufficiently like the original. | |
| 61 | - | |
| 62 | - This chain of signatures prevents both types of forgery, and it is a | |
| 63 | - second type of link between the blocks, separate from the “hash | |
| 64 | - chain” that applies an ordering to the blocks. (This distinction of | |
| 65 | - terms comes from [_Blockchain: Simple Explanation_][bse].) | |
| 66 | - | |
| 67 | - Fossil has an off-by-default feature to call out to an external copy | |
| 68 | - of PGP or GPG to sign commit manifests before inserting them into | |
| 69 | - the repository, but it’s rarely used, and even when it is used, | |
| 70 | - Fossil doesn’t currently verify those signatures in any way. | |
| 71 | - | |
| 72 | - Even if Fossil someday gets a built-in commit signature feature, and | |
| 73 | - even if this new feature enforces a rule that rejects commits that | |
| 74 | - don’t include a verifiable signature, Fossil will still not provide | |
| 75 | - the sort of cross-block transfer signatures needed by | |
| 76 | - cryptocurrencies. Fossil commit signatures simply attest that the | |
| 77 | - new commit was created by some verifiable person while preventing | |
| 78 | - that attestation and the block it attests to from being changed. (A | |
| 79 | - failure in this feature would be analogous to the first type of | |
| 80 | - forgery above: changing the “face value” of a commit.) As long as I | |
| 81 | - retain control over my private commit signing key, no one can take | |
| 82 | - one of my commits and change its contents. | |
| 83 | - | |
| 84 | - There is no need in Fossil for cross-commit sign-overs, because | |
| 85 | - there is no useful analog to double-spending fraud in Fossil. | |
| 86 | - | |
| 87 | - The lack of commit signing in the default Fossil configuration means | |
| 88 | - forgery of commits is possible by anyone with commit capability. If | |
| 89 | - that is an essential element to your notion of “blockchain,” and you | |
| 90 | - wish to have some of the same guarantees from Fossil as you get from | |
| 91 | - other types of blockchains, then you should enable its [clearsign | |
| 92 | - feature][cs], coupled with a server-side [“after receive” hook][arh] | |
| 93 | - to reject commits if they aren’t signed. | |
| 94 | - | |
| 95 | - Fossil’s chain of hashes prevents modification of existing commits | |
| 96 | - as long as the receiving Fossil server is secure. Even if you manage | |
| 97 | - to execute a [preimage attack][prei] on the hash algorthm — SHA3-256 | |
| 98 | - by default in the current version of Fossil — our sync protocol will | |
| 99 | - prevent the modification from being accepted into the repository. To | |
| 100 | - modify an existing commit, an attacker would have to attack the | |
| 101 | - remote host itself somehow, not its repository data structures. | |
| 102 | - Strong signatures are only needed to prevent *new* commits from | |
| 103 | - being forged at the tips of the DAG, and to avoid the need to trust | |
| 104 | - the remote Fossil server quite so heavily. | |
| 105 | - | |
| 106 | - If you’re wondering why Fossil currently lacks built-in commit | |
| 107 | - signing and verification, and why its current commit signing feature | |
| 108 | - is not enabled by default, it is because Fossil is not itself a | |
| 109 | - [PKI], and there is no way for regular users of Fossil to link it to | |
| 110 | - a PKI, since doing so would likely result in an unwanted [PII] | |
| 111 | - disclosure. There is no email address in a Fossil commit manifest | |
| 112 | - that you could use to query one of the public PGP keyservers, for | |
| 113 | - example. It therefore becomes a local policy matter as to whether | |
| 114 | - you even *want* to have signatures, because they’re not without | |
| 115 | - their downsides. | |
| 116 | - | |
| 117 | -2. **Longest-Chain Rule.** Cryptocurrencies generally need some way to | |
| 118 | - distinguish which blocks are legitimate and which not. | |
| 119 | - | |
| 120 | - There is the proof-of-work aspect of this, which has no useful | |
| 121 | - application to Fossil, so we can ignore that. | |
| 122 | - | |
| 123 | - The other aspect of this does have applicability to Fossil is the | |
| 124 | - notion (as in Bitcoin) that the linear chain with the greatest | |
| 125 | - cumulative work-time is the legitimate chain. Everything else is | |
| 126 | - considered an “orphan” block and is ignored by the software. The | |
| 127 | - closest we can come to that notion in Fossil is the default “trunk” | |
| 128 | - branch, but there’s nothing in Fossil that delegitimizes other | |
| 129 | - branches just because they’re shorter, nor is there any way in | |
| 130 | - Fossil to score the amount of work that went into a commit. Indeed, | |
| 131 | - [forks and branches][fb] are *valuable and desirable* things in | |
| 132 | - Fossil. | |
| 133 | - | |
| 134 | -3. **Work Contests.** Cryptocurrencies prevent forgery by setting up | |
| 135 | - some sort of contest that ensures that new coins can come into | |
| 136 | - existence only by doing some difficult work task. This “mining” | |
| 53 | +Cryptocurrencies must prevent three separate types of fraud to be useful: | |
| 54 | + | |
| 55 | +* **Type 1** is modification of existing currency. To draw an analogy | |
| 56 | + to paper money, we wish to prevent someone from using green and | |
| 57 | + black markers to draw extra zeroes on a US $10 bill so that it | |
| 58 | + claims to be a $100 bill. Cryptocurrencies apply digital signatures | |
| 59 | + to each block so that a given block of currency’s face value cannot | |
| 60 | + be changed after it is created. The [proof-of-work][pow] aspect | |
| 61 | + prevents the creator from setting its initial value fraudulently. | |
| 62 | + | |
| 63 | +* **Type 2** is making new counterfeit $10 bills that look | |
| 64 | + sufficiently like the original to pass in commerce. Cryptocurrencies | |
| 65 | + chain blocks together and establish a sufficiently hard work problem | |
| 66 | + to create new currency that Type 2 frauds are impractical short of | |
| 67 | + doing the actual mining needed to produce legitimate cryptocurrency. | |
| 68 | + | |
| 69 | +* **Type 3** is double-spending existing legitimate cryptocurrency. | |
| 70 | + There is no analogy in paper money due to its physical form; it is a | |
| 71 | + problem unique to digital currency due to its infinitely-copyable | |
| 72 | + nature. Cryptocurrencies prevent Type 3 frauds by making the | |
| 73 | + *prior* owner of a block sign it over to the new owner. To avoid an | |
| 74 | + O(n²) auditing problem as a result, cryptocurrencies also use a | |
| 75 | + chain of hashes to make checking for double-spending quick and easy. | |
| 76 | + | |
| 77 | +How does all of this compare to Fossil? | |
| 78 | + | |
| 79 | +1. <a id="signatures"></a>**Signatures.** Cryptocurrencies use a chain | |
| 80 | + of [digital signatures][dsig] to prevent Type 1 and Type 3 frauds. This | |
| 81 | + chain forms an additional link between the blocks, separate from the | |
| 82 | + hash chain that applies an ordering and lookup scheme to the blocks. | |
| 83 | + [_Blockchain: Simple Explanation_][bse] explains this “hash chain” | |
| 84 | + vs. “block chain” distinction in more detail. | |
| 85 | + | |
| 86 | + Fossil has [a disabled-by-default feature][cs] to call out to an | |
| 87 | + external copy of [PGP] or [GPG] to sign commit manifests before | |
| 88 | + inserting them into the repository. You may wish to couple that with | |
| 89 | + a server-side [after-receive hook][arh] to reject unsigned commits. | |
| 90 | + | |
| 91 | + Although there are several distinctions you can draw between the way | |
| 92 | + Fossil’s commit signing scheme works and the way block signing works | |
| 93 | + in cryptocurrencies, only one is of material interest for our | |
| 94 | + purposes here: Fossil commit signatures apply only to a single | |
| 95 | + commit. Fossil does not sign one commit over to the next “owner” of | |
| 96 | + that commit in the way that a blockchain-based cryptocurrency must | |
| 97 | + when transferring currency from one user to another, beacuse there | |
| 98 | + is no useful analog to the double-spending problem in Fossil. The | |
| 99 | + closest you can come to this is double-insert of commits into the | |
| 100 | + blockchain, which we’ll address shortly. | |
| 101 | + | |
| 102 | + What Fossil commit signatures actually do is provide in-tree forgery | |
| 103 | + prevention, both Type 1 and Type 2. You cannot modify existing | |
| 104 | + commits (Type 1 forgery) because you do not have the original | |
| 105 | + committer’s private signing key, and you cannot forge new commits | |
| 106 | + attesting to come from some other trusted committer (Type 2) because | |
| 107 | + you don’t have any of their private signing keys, either. | |
| 108 | + Cyrptocurrencies also use the work problem to prevent Type 2 | |
| 109 | + forgeries, but the application of that to Fossil is a matter we get | |
| 110 | + to [later](#work). | |
| 111 | + | |
| 112 | + If Fossil signatures prevent Type 1 and Type 2 frauds, why then are | |
| 113 | + they not enabled by default? Because they are defense-in-depth | |
| 114 | + measures, not the minimum sufficient measures needed to prevent | |
| 115 | + repository fraud in Fossil. Fossil provides its primary protections | |
| 116 | + through other means. | |
| 117 | + | |
| 118 | + Although you have complete control over the contents of your local | |
| 119 | + Fossil repository clone, you cannot perform Type 1 forgery on its | |
| 120 | + contents short of executing a [preimage attack][prei] on the hash | |
| 121 | + algorthm. ([SHA3-256][SHA-3] by default in the current version of | |
| 122 | + Fossil.) Even if you could, Fossil’s sync protocol will prevent the | |
| 123 | + modification from being pushed into another repository: the remote | |
| 124 | + Fossil instance says, “I’ve already got that one, thanks,” and | |
| 125 | + ignores the push. Thus, short of breaking into the remote server | |
| 126 | + and modifying the repository in place, you couldn’t even make use of | |
| 127 | + a preimage attack if you had that power. This is an attack on the | |
| 128 | + server itself, not on Fossil’s data structures, so while it is | |
| 129 | + useful to think through this problem, it is not helpful to answering | |
| 130 | + our questions here. | |
| 131 | + | |
| 132 | + The Fossil sync protocol also prevents the closest analog to Type 3 | |
| 133 | + frauds in Fossil: copying a commit manifest in your local repo clone | |
| 134 | + won’t result in a double-commit on sync. | |
| 135 | + | |
| 136 | + In the absence of digital signatures, Fossil’s [RBAC system][caps] | |
| 137 | + restricts Type 2 forgery to trusted committers. Thus once again | |
| 138 | + we’re reduced to an infosec problem, not a data structure design | |
| 139 | + question. (Inversely, enabling commit clearsigning is a good idea | |
| 140 | + if you have committers on your repo whom you don’t trust not to | |
| 141 | + commit Type 2 frauds. But let us be clear: your choice of setting | |
| 142 | + does not answer the question of whether Fossil is a blockchain.) | |
| 143 | + | |
| 144 | + If you’re wondering why Fossil’s current commit signing feature is | |
| 145 | + not enabled by default and why it doesn’t verify signatures on | |
| 146 | + commits, it is because Fossil is not itself a [PKI], and there is no | |
| 147 | + way for regular users of Fossil to link it to a PKI, since doing so | |
| 148 | + would likely result in an unwanted [PII] disclosure. There is no | |
| 149 | + email address in a Fossil commit manifest that you could use to | |
| 150 | + query one of the public PGP keyservers, for example. It therefore | |
| 151 | + becomes a local policy matter as to whether you even *want* to have | |
| 152 | + signatures, because they’re not without their downsides. | |
| 153 | + | |
| 154 | +2. <a id="work"></a>**Work Contests.** Cryptocurrencies prevent forgery | |
| 155 | + by setting up some sort of contest that ensures that new coins can come | |
| 156 | + into existence only by doing some difficult work task. This “mining” | |
| 137 | 157 | activity results in a coin that took considerable work to create, |
| 138 | 158 | which thus has economic value by being a) difficult to re-create, |
| 139 | 159 | and b) resistant to [debasement][dboc]. |
| 140 | 160 | |
| 141 | 161 | Fossil repositories are most often used to store the work product of |
| 142 | 162 | individuals, rather than cryptocoin mining machines. There is |
| 143 | - generally no contest in trying to produce the most commits. | |
| 163 | + generally no contest in trying to produce the most commits. There | |
| 164 | + may be an implicit contest to produce the “best” commits, but that | |
| 165 | + is a matter of project management, not something that can be | |
| 166 | + automatically mediated through objective measures. | |
| 167 | + | |
| 144 | 168 | Incentives to commit to the repository come from outside of Fossil; |
| 145 | 169 | they are not inherent to its nature, as with cryptocurrencies. |
| 146 | 170 | Moreover, there is no useful sense in which we could say that one |
| 147 | 171 | commit “re-creates” another. Commits are generally products of |
| 148 | 172 | individual human intellect, thus necessarily unique in all but |
| 149 | - trivial cases. Thus the entire basis of copyright law. | |
| 173 | + trivial cases. This is foundational to copyright law. | |
| 174 | + | |
| 175 | +3. <a id="lcr"></a>**Longest-Chain Rule.** Cryptocurrencies generally | |
| 176 | + need some way to distinguish which blocks are legitimate and which | |
| 177 | + not. They do this in part by identifying the linear chain with the | |
| 178 | + greatest cumulative [work time](#work) as the legitimate chain. All | |
| 179 | + blocks not on that linear chain are considered “orphans” and are | |
| 180 | + ignored by the cryptocurrency software. | |
| 181 | + | |
| 182 | + The closest we can come to that notion in Fossil is the default | |
| 183 | + “trunk” branch, but there’s nothing in Fossil that delegitimizes | |
| 184 | + other branches just because they’re shorter, nor is there any way in | |
| 185 | + Fossil to score the amount of work that went into a commit. Indeed, | |
| 186 | + [forks and branches][fb] are *valuable and desirable* things in | |
| 187 | + Fossil. | |
| 150 | 188 | |
| 151 | -This much is certain: Fossil is definitely not a cryptocurrency. | |
| 189 | +This much is certain: Fossil is definitely not a cryptocurrency. Whether | |
| 190 | +this makes it “not a blockchain” is a subjective matter. | |
| 152 | 191 | |
| 153 | 192 | [arh]: https://fossil-scm.org/fossil/doc/trunk/www/hooks.md |
| 154 | 193 | [bse]: https://www.researchgate.net/publication/311572122_What_is_Blockchain_a_Gentle_Introduction |
| 194 | +[caps]: ./caps/ | |
| 155 | 195 | [cs]: https://fossil-scm.org/home/help?cmd=clearsign |
| 156 | 196 | [dboc]: https://en.wikipedia.org/wiki/Debasement |
| 197 | +[dsig]: https://en.wikipedia.org/wiki/Digital_signature | |
| 157 | 198 | [fb]: https://fossil-scm.org/home/doc/trunk/www/branching.wiki |
| 199 | +[GPG]: https://gnupg.org/ | |
| 200 | +[PGP]: https://www.openpgp.org/ | |
| 158 | 201 | [PII]: https://en.wikipedia.org/wiki/Personal_data |
| 159 | 202 | [PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure |
| 203 | +[pow]: https://en.wikipedia.org/wiki/Proof_of_work | |
| 160 | 204 | [prei]: https://en.wikipedia.org/wiki/Preimage_attack |
| 161 | 205 | |
| 162 | 206 | |
| 163 | 207 | |
| 164 | 208 | ## Distributed Ledgers |
| 165 | 209 | |
| 166 | -Cryptocurrencies are a type of [distributed ledger technology][dlt]. If | |
| 167 | -we can convince ourselves that Fossil is also a type of distributed | |
| 168 | -ledger, then we might think of Fossil as a peer technology, thus also a | |
| 169 | -type of blockchain. | |
| 210 | +Cryptocurrencies are an instance of [distributed ledger technology][dlt]. If | |
| 211 | +we can convince ourselves that Fossil is also a distributed | |
| 212 | +ledger, then we might think of Fossil as at least a peer technology, | |
| 213 | +having at least some qualifications toward being considered a blockchain. | |
| 170 | 214 | |
| 171 | 215 | A key tenet of DLT is that records be unmodifiable after they’re |
| 172 | 216 | committed to the ledger, which matches quite well with Fossil’s design |
| 173 | 217 | and everyday use cases. Fossil puts up multiple barriers to prevent |
| 174 | 218 | modification of existing records and injection of incorrect records. |
| 175 | 219 | |
| 176 | 220 | Yet, Fossil also has [purge] and [shunning][shun]. Doesn’t that mean |
| 177 | 221 | Fossil cannot be a distributed ledger? |
| 178 | 222 | |
| 179 | -These features remove commits from the repository. If you want a | |
| 223 | +These features only remove existing commits from the repository. If you want a | |
| 180 | 224 | currency analogy, they are ways to burn a paper bill or to melt a [fiat |
| 181 | 225 | coin][fc] down to slag. In a cryptocurrency, you can erase your “wallet” |
| 182 | -file, effectively destroying money in a similar way. You can’t use these | |
| 183 | -features of Fossil to forge new commits or forge a modification to an | |
| 184 | -existing commit. | |
| 226 | +file, effectively destroying money in a similar way. These features | |
| 227 | +do not permit forgery of either type described above: you can’t use them | |
| 228 | +to change the value of existing commits (Type 1) or add new commits to | |
| 229 | +the repository (Type 2). | |
| 185 | 230 | |
| 186 | 231 | What if we removed those features from Fossil, creating an append-only |
| 187 | -variant? Is it a DLT then? Arguably still not, because [today’s Fossil | |
| 188 | -is an AP-mode system][fapm] in the [CAP theorem][cap] sense, which means | |
| 232 | +Fossil variant? Is it a DLT then? Arguably still not, because [today’s Fossil | |
| 233 | +is an AP-mode system][ctap] in the [CAP theorem][cap] sense, which means | |
| 189 | 234 | there can be no guaranteed consensus on the content of the ledger at any |
| 190 | 235 | given time. If you had an AP-mode accounts receivable system, it could |
| 191 | 236 | have different bottom-line totals at different sites, because you’ve |
| 192 | 237 | cast away “C” to get AP-mode operation. |
| 238 | + | |
| 239 | +Because of this, you could still not guarantee that the command “`fossil | |
| 240 | +info tip`” gives the same result everywhere. A CA or CP-mode Fossil | |
| 241 | +variant would guarantee that everyone got the same result. (Everyone not | |
| 242 | +partitioned away from the majority of the network at any rate, in the CP | |
| 243 | +case.) | |
| 193 | 244 | |
| 194 | 245 | What are the prospects for CA-mode or CP-mode Fossil? [We don’t want |
| 195 | -CA-mode Fossil, but CP-mode could be useful.][fapm] Until the latter | |
| 246 | +CA-mode Fossil][ctca], but [CP-mode could be useful][ctcp]. Until the latter | |
| 196 | 247 | exists, this author believes Fossil is not a distributed ledger in a |
| 197 | 248 | technologically defensible sense. |
| 198 | 249 | |
| 199 | 250 | The most common technologies answering to the label “blockchain” are all |
| 200 | 251 | DLTs, so if Fossil is not a DLT, then it is not a blockchain in that |
| 201 | 252 | sense. |
| 202 | 253 | |
| 203 | -[fapm]: ./cap-theorem.md | |
| 254 | +[ctap]: ./cap-theorem.md#ap | |
| 255 | +[ctca]: ./cap-theorem.md#ca | |
| 256 | +[ctcp]: ./cap-theorem.md#cp | |
| 204 | 257 | [cap]: https://en.wikipedia.org/wiki/CAP_theorem |
| 205 | 258 | [dlt]: https://en.wikipedia.org/wiki/Distributed_ledger |
| 206 | 259 | [DVCS]: https://en.wikipedia.org/wiki/Distributed_version_control |
| 207 | 260 | [fc]: https://en.wikipedia.org/wiki/Fiat_money |
| 208 | 261 | [purge]: /help?cmd=purge |
| @@ -250,11 +303,11 @@ | ||
| 250 | 303 | since you can’t verify the proofs of these signatures if you can’t first |
| 251 | 304 | prove that the provided signatures belong to people you trust. This is a |
| 252 | 305 | notoriously hard problem in its own right. |
| 253 | 306 | |
| 254 | 307 | A future version of Fossil could instead provide consensus [in the CAP |
| 255 | -sense][fapm]. For instance, you could say that if a quorum of servers | |
| 308 | +sense][cacp]. For instance, you could say that if a quorum of servers | |
| 256 | 309 | all have a given commit, it “belongs.” Fossil’s strong hashing tech |
| 257 | 310 | would mean that querying whether a given commit is part of the |
| 258 | 311 | “blockchain” would be as simple as going down the list of servers and |
| 259 | 312 | sending it an HTTP GET `/info` query for the artifact ID, returning |
| 260 | 313 | “Yes” once you get enough HTTP 200 status codes back. All of this is |
| @@ -275,16 +328,17 @@ | ||
| 275 | 328 | doesn’t work to use a term in a nonstandard way just because you can |
| 276 | 329 | defend it. The people you’re communicating your ideas to must have the |
| 277 | 330 | same concept of the terms you use. |
| 278 | 331 | |
| 279 | 332 | |
| 280 | -What term should you use instead? A blockchain is a type of [Merkle | |
| 281 | -tree][mt], named after [its inventor][drrm]. You could also call it by | |
| 282 | -the more generic term “hash tree.” That Fossil certainly is. | |
| 333 | +What term should you use instead? Fossil stores a DAG of hash-chained | |
| 334 | +commits, so an indisputably correct term is a [Merkle tree][mt], named | |
| 335 | +after [its inventor][drrm]. You could also use the more generic term | |
| 336 | +“hash tree.” | |
| 283 | 337 | |
| 284 | -Fossil is a technological peer to many common types of blockchain | |
| 338 | +Fossil is a technological peer to many common sorts of blockchain | |
| 285 | 339 | technology. There is a lot of overlap in concepts and implementation |
| 286 | 340 | details, but when speaking of what most people understand as |
| 287 | 341 | “blockchain,” Fossil is not that. |
| 288 | 342 | |
| 289 | 343 | [drrm]: https://en.wikipedia.org/wiki/Ralph_Merkle |
| 290 | 344 | [mt]: https://en.wikipedia.org/wiki/Merkle_tree |
| 291 | 345 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -25,11 +25,11 @@ | |
| 25 | you traverse the Fossil repository from the tips of its [DAG] to the |
| 26 | root by following the parent hashes in each manifest, you will then have |
| 27 | a Merkle tree. Point-for-point, Fossil follows that definition. |
| 28 | |
| 29 | Every change in Fossil starts by adding one or more manifests to |
| 30 | the repository. |
| 31 | |
| 32 | [bcwp]: https://en.wikipedia.org/wiki/Blockchain |
| 33 | [DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph |
| 34 | [SHA-1]: https://en.wikipedia.org/wiki/SHA-1 |
| 35 | [SHA-3]: https://en.wikipedia.org/wiki/SHA-3 |
| @@ -38,171 +38,224 @@ | |
| 38 | |
| 39 | ## Cryptocurrency |
| 40 | |
| 41 | Because blockchain technology was first popularized as Bitcoin, many |
| 42 | people associate the term with cryptocurrency. Fossil has nothing to do |
| 43 | with cryptocurrency, so a claim that “Fossil is a blockchain” may run up |
| 44 | against problems due to conflation with cryptocurrency. |
| 45 | |
| 46 | Cryptocurrency has several features and requirements that Fossil doesn’t |
| 47 | provide, either because it doesn’t need them or because we haven’t |
| 48 | gotten around to creating the feature. Whether these are essential to |
| 49 | the definition of “blockchain” and thus make Fossil “not a blockchain” |
| 50 | is for you to decide. |
| 51 | |
| 52 | 1. **Signatures.** Blocks in a cryptocurrency have to be signed by the |
| 53 | *prior* owner of each block in order to transfer the money to the |
| 54 | new holder, else the new recipient could claim to have received any |
| 55 | amount of money they want by editing the face value of the currency |
| 56 | block. The chain of signatures also lets us verify that each block |
| 57 | is transferred only once, solving the double-spending problem. These |
| 58 | are both types of forgery, but they’re distinct sorts: changing a |
| 59 | US $20 bill to $100 is different from simply making more $20 bills |
| 60 | that look sufficiently like the original. |
| 61 | |
| 62 | This chain of signatures prevents both types of forgery, and it is a |
| 63 | second type of link between the blocks, separate from the “hash |
| 64 | chain” that applies an ordering to the blocks. (This distinction of |
| 65 | terms comes from [_Blockchain: Simple Explanation_][bse].) |
| 66 | |
| 67 | Fossil has an off-by-default feature to call out to an external copy |
| 68 | of PGP or GPG to sign commit manifests before inserting them into |
| 69 | the repository, but it’s rarely used, and even when it is used, |
| 70 | Fossil doesn’t currently verify those signatures in any way. |
| 71 | |
| 72 | Even if Fossil someday gets a built-in commit signature feature, and |
| 73 | even if this new feature enforces a rule that rejects commits that |
| 74 | don’t include a verifiable signature, Fossil will still not provide |
| 75 | the sort of cross-block transfer signatures needed by |
| 76 | cryptocurrencies. Fossil commit signatures simply attest that the |
| 77 | new commit was created by some verifiable person while preventing |
| 78 | that attestation and the block it attests to from being changed. (A |
| 79 | failure in this feature would be analogous to the first type of |
| 80 | forgery above: changing the “face value” of a commit.) As long as I |
| 81 | retain control over my private commit signing key, no one can take |
| 82 | one of my commits and change its contents. |
| 83 | |
| 84 | There is no need in Fossil for cross-commit sign-overs, because |
| 85 | there is no useful analog to double-spending fraud in Fossil. |
| 86 | |
| 87 | The lack of commit signing in the default Fossil configuration means |
| 88 | forgery of commits is possible by anyone with commit capability. If |
| 89 | that is an essential element to your notion of “blockchain,” and you |
| 90 | wish to have some of the same guarantees from Fossil as you get from |
| 91 | other types of blockchains, then you should enable its [clearsign |
| 92 | feature][cs], coupled with a server-side [“after receive” hook][arh] |
| 93 | to reject commits if they aren’t signed. |
| 94 | |
| 95 | Fossil’s chain of hashes prevents modification of existing commits |
| 96 | as long as the receiving Fossil server is secure. Even if you manage |
| 97 | to execute a [preimage attack][prei] on the hash algorthm — SHA3-256 |
| 98 | by default in the current version of Fossil — our sync protocol will |
| 99 | prevent the modification from being accepted into the repository. To |
| 100 | modify an existing commit, an attacker would have to attack the |
| 101 | remote host itself somehow, not its repository data structures. |
| 102 | Strong signatures are only needed to prevent *new* commits from |
| 103 | being forged at the tips of the DAG, and to avoid the need to trust |
| 104 | the remote Fossil server quite so heavily. |
| 105 | |
| 106 | If you’re wondering why Fossil currently lacks built-in commit |
| 107 | signing and verification, and why its current commit signing feature |
| 108 | is not enabled by default, it is because Fossil is not itself a |
| 109 | [PKI], and there is no way for regular users of Fossil to link it to |
| 110 | a PKI, since doing so would likely result in an unwanted [PII] |
| 111 | disclosure. There is no email address in a Fossil commit manifest |
| 112 | that you could use to query one of the public PGP keyservers, for |
| 113 | example. It therefore becomes a local policy matter as to whether |
| 114 | you even *want* to have signatures, because they’re not without |
| 115 | their downsides. |
| 116 | |
| 117 | 2. **Longest-Chain Rule.** Cryptocurrencies generally need some way to |
| 118 | distinguish which blocks are legitimate and which not. |
| 119 | |
| 120 | There is the proof-of-work aspect of this, which has no useful |
| 121 | application to Fossil, so we can ignore that. |
| 122 | |
| 123 | The other aspect of this does have applicability to Fossil is the |
| 124 | notion (as in Bitcoin) that the linear chain with the greatest |
| 125 | cumulative work-time is the legitimate chain. Everything else is |
| 126 | considered an “orphan” block and is ignored by the software. The |
| 127 | closest we can come to that notion in Fossil is the default “trunk” |
| 128 | branch, but there’s nothing in Fossil that delegitimizes other |
| 129 | branches just because they’re shorter, nor is there any way in |
| 130 | Fossil to score the amount of work that went into a commit. Indeed, |
| 131 | [forks and branches][fb] are *valuable and desirable* things in |
| 132 | Fossil. |
| 133 | |
| 134 | 3. **Work Contests.** Cryptocurrencies prevent forgery by setting up |
| 135 | some sort of contest that ensures that new coins can come into |
| 136 | existence only by doing some difficult work task. This “mining” |
| 137 | activity results in a coin that took considerable work to create, |
| 138 | which thus has economic value by being a) difficult to re-create, |
| 139 | and b) resistant to [debasement][dboc]. |
| 140 | |
| 141 | Fossil repositories are most often used to store the work product of |
| 142 | individuals, rather than cryptocoin mining machines. There is |
| 143 | generally no contest in trying to produce the most commits. |
| 144 | Incentives to commit to the repository come from outside of Fossil; |
| 145 | they are not inherent to its nature, as with cryptocurrencies. |
| 146 | Moreover, there is no useful sense in which we could say that one |
| 147 | commit “re-creates” another. Commits are generally products of |
| 148 | individual human intellect, thus necessarily unique in all but |
| 149 | trivial cases. Thus the entire basis of copyright law. |
| 150 | |
| 151 | This much is certain: Fossil is definitely not a cryptocurrency. |
| 152 | |
| 153 | [arh]: https://fossil-scm.org/fossil/doc/trunk/www/hooks.md |
| 154 | [bse]: https://www.researchgate.net/publication/311572122_What_is_Blockchain_a_Gentle_Introduction |
| 155 | [cs]: https://fossil-scm.org/home/help?cmd=clearsign |
| 156 | [dboc]: https://en.wikipedia.org/wiki/Debasement |
| 157 | [fb]: https://fossil-scm.org/home/doc/trunk/www/branching.wiki |
| 158 | [PII]: https://en.wikipedia.org/wiki/Personal_data |
| 159 | [PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure |
| 160 | [prei]: https://en.wikipedia.org/wiki/Preimage_attack |
| 161 | |
| 162 | |
| 163 | |
| 164 | ## Distributed Ledgers |
| 165 | |
| 166 | Cryptocurrencies are a type of [distributed ledger technology][dlt]. If |
| 167 | we can convince ourselves that Fossil is also a type of distributed |
| 168 | ledger, then we might think of Fossil as a peer technology, thus also a |
| 169 | type of blockchain. |
| 170 | |
| 171 | A key tenet of DLT is that records be unmodifiable after they’re |
| 172 | committed to the ledger, which matches quite well with Fossil’s design |
| 173 | and everyday use cases. Fossil puts up multiple barriers to prevent |
| 174 | modification of existing records and injection of incorrect records. |
| 175 | |
| 176 | Yet, Fossil also has [purge] and [shunning][shun]. Doesn’t that mean |
| 177 | Fossil cannot be a distributed ledger? |
| 178 | |
| 179 | These features remove commits from the repository. If you want a |
| 180 | currency analogy, they are ways to burn a paper bill or to melt a [fiat |
| 181 | coin][fc] down to slag. In a cryptocurrency, you can erase your “wallet” |
| 182 | file, effectively destroying money in a similar way. You can’t use these |
| 183 | features of Fossil to forge new commits or forge a modification to an |
| 184 | existing commit. |
| 185 | |
| 186 | What if we removed those features from Fossil, creating an append-only |
| 187 | variant? Is it a DLT then? Arguably still not, because [today’s Fossil |
| 188 | is an AP-mode system][fapm] in the [CAP theorem][cap] sense, which means |
| 189 | there can be no guaranteed consensus on the content of the ledger at any |
| 190 | given time. If you had an AP-mode accounts receivable system, it could |
| 191 | have different bottom-line totals at different sites, because you’ve |
| 192 | cast away “C” to get AP-mode operation. |
| 193 | |
| 194 | What are the prospects for CA-mode or CP-mode Fossil? [We don’t want |
| 195 | CA-mode Fossil, but CP-mode could be useful.][fapm] Until the latter |
| 196 | exists, this author believes Fossil is not a distributed ledger in a |
| 197 | technologically defensible sense. |
| 198 | |
| 199 | The most common technologies answering to the label “blockchain” are all |
| 200 | DLTs, so if Fossil is not a DLT, then it is not a blockchain in that |
| 201 | sense. |
| 202 | |
| 203 | [fapm]: ./cap-theorem.md |
| 204 | [cap]: https://en.wikipedia.org/wiki/CAP_theorem |
| 205 | [dlt]: https://en.wikipedia.org/wiki/Distributed_ledger |
| 206 | [DVCS]: https://en.wikipedia.org/wiki/Distributed_version_control |
| 207 | [fc]: https://en.wikipedia.org/wiki/Fiat_money |
| 208 | [purge]: /help?cmd=purge |
| @@ -250,11 +303,11 @@ | |
| 250 | since you can’t verify the proofs of these signatures if you can’t first |
| 251 | prove that the provided signatures belong to people you trust. This is a |
| 252 | notoriously hard problem in its own right. |
| 253 | |
| 254 | A future version of Fossil could instead provide consensus [in the CAP |
| 255 | sense][fapm]. For instance, you could say that if a quorum of servers |
| 256 | all have a given commit, it “belongs.” Fossil’s strong hashing tech |
| 257 | would mean that querying whether a given commit is part of the |
| 258 | “blockchain” would be as simple as going down the list of servers and |
| 259 | sending it an HTTP GET `/info` query for the artifact ID, returning |
| 260 | “Yes” once you get enough HTTP 200 status codes back. All of this is |
| @@ -275,16 +328,17 @@ | |
| 275 | doesn’t work to use a term in a nonstandard way just because you can |
| 276 | defend it. The people you’re communicating your ideas to must have the |
| 277 | same concept of the terms you use. |
| 278 | |
| 279 | |
| 280 | What term should you use instead? A blockchain is a type of [Merkle |
| 281 | tree][mt], named after [its inventor][drrm]. You could also call it by |
| 282 | the more generic term “hash tree.” That Fossil certainly is. |
| 283 | |
| 284 | Fossil is a technological peer to many common types of blockchain |
| 285 | technology. There is a lot of overlap in concepts and implementation |
| 286 | details, but when speaking of what most people understand as |
| 287 | “blockchain,” Fossil is not that. |
| 288 | |
| 289 | [drrm]: https://en.wikipedia.org/wiki/Ralph_Merkle |
| 290 | [mt]: https://en.wikipedia.org/wiki/Merkle_tree |
| 291 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -25,11 +25,11 @@ | |
| 25 | you traverse the Fossil repository from the tips of its [DAG] to the |
| 26 | root by following the parent hashes in each manifest, you will then have |
| 27 | a Merkle tree. Point-for-point, Fossil follows that definition. |
| 28 | |
| 29 | Every change in Fossil starts by adding one or more manifests to |
| 30 | the repository, extending this tree. |
| 31 | |
| 32 | [bcwp]: https://en.wikipedia.org/wiki/Blockchain |
| 33 | [DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph |
| 34 | [SHA-1]: https://en.wikipedia.org/wiki/SHA-1 |
| 35 | [SHA-3]: https://en.wikipedia.org/wiki/SHA-3 |
| @@ -38,171 +38,224 @@ | |
| 38 | |
| 39 | ## Cryptocurrency |
| 40 | |
| 41 | Because blockchain technology was first popularized as Bitcoin, many |
| 42 | people associate the term with cryptocurrency. Fossil has nothing to do |
| 43 | with cryptocurrency, so a claim that “Fossil is a blockchain” may fail |
| 44 | to communicate the speaker’s concepts clearly due to conflation with |
| 45 | cryptocurrency. |
| 46 | |
| 47 | Cryptocurrency has several features and requirements that Fossil doesn’t |
| 48 | provide, either because it doesn’t need them or because we haven’t |
| 49 | gotten around to creating the feature. Whether these are essential to |
| 50 | the definition of “blockchain” and thus disqualify Fossil as a blockchain |
| 51 | is for you to decide. |
| 52 | |
| 53 | Cryptocurrencies must prevent three separate types of fraud to be useful: |
| 54 | |
| 55 | * **Type 1** is modification of existing currency. To draw an analogy |
| 56 | to paper money, we wish to prevent someone from using green and |
| 57 | black markers to draw extra zeroes on a US $10 bill so that it |
| 58 | claims to be a $100 bill. Cryptocurrencies apply digital signatures |
| 59 | to each block so that a given block of currency’s face value cannot |
| 60 | be changed after it is created. The [proof-of-work][pow] aspect |
| 61 | prevents the creator from setting its initial value fraudulently. |
| 62 | |
| 63 | * **Type 2** is making new counterfeit $10 bills that look |
| 64 | sufficiently like the original to pass in commerce. Cryptocurrencies |
| 65 | chain blocks together and establish a sufficiently hard work problem |
| 66 | to create new currency that Type 2 frauds are impractical short of |
| 67 | doing the actual mining needed to produce legitimate cryptocurrency. |
| 68 | |
| 69 | * **Type 3** is double-spending existing legitimate cryptocurrency. |
| 70 | There is no analogy in paper money due to its physical form; it is a |
| 71 | problem unique to digital currency due to its infinitely-copyable |
| 72 | nature. Cryptocurrencies prevent Type 3 frauds by making the |
| 73 | *prior* owner of a block sign it over to the new owner. To avoid an |
| 74 | O(n²) auditing problem as a result, cryptocurrencies also use a |
| 75 | chain of hashes to make checking for double-spending quick and easy. |
| 76 | |
| 77 | How does all of this compare to Fossil? |
| 78 | |
| 79 | 1. <a id="signatures"></a>**Signatures.** Cryptocurrencies use a chain |
| 80 | of [digital signatures][dsig] to prevent Type 1 and Type 3 frauds. This |
| 81 | chain forms an additional link between the blocks, separate from the |
| 82 | hash chain that applies an ordering and lookup scheme to the blocks. |
| 83 | [_Blockchain: Simple Explanation_][bse] explains this “hash chain” |
| 84 | vs. “block chain” distinction in more detail. |
| 85 | |
| 86 | Fossil has [a disabled-by-default feature][cs] to call out to an |
| 87 | external copy of [PGP] or [GPG] to sign commit manifests before |
| 88 | inserting them into the repository. You may wish to couple that with |
| 89 | a server-side [after-receive hook][arh] to reject unsigned commits. |
| 90 | |
| 91 | Although there are several distinctions you can draw between the way |
| 92 | Fossil’s commit signing scheme works and the way block signing works |
| 93 | in cryptocurrencies, only one is of material interest for our |
| 94 | purposes here: Fossil commit signatures apply only to a single |
| 95 | commit. Fossil does not sign one commit over to the next “owner” of |
| 96 | that commit in the way that a blockchain-based cryptocurrency must |
| 97 | when transferring currency from one user to another, beacuse there |
| 98 | is no useful analog to the double-spending problem in Fossil. The |
| 99 | closest you can come to this is double-insert of commits into the |
| 100 | blockchain, which we’ll address shortly. |
| 101 | |
| 102 | What Fossil commit signatures actually do is provide in-tree forgery |
| 103 | prevention, both Type 1 and Type 2. You cannot modify existing |
| 104 | commits (Type 1 forgery) because you do not have the original |
| 105 | committer’s private signing key, and you cannot forge new commits |
| 106 | attesting to come from some other trusted committer (Type 2) because |
| 107 | you don’t have any of their private signing keys, either. |
| 108 | Cyrptocurrencies also use the work problem to prevent Type 2 |
| 109 | forgeries, but the application of that to Fossil is a matter we get |
| 110 | to [later](#work). |
| 111 | |
| 112 | If Fossil signatures prevent Type 1 and Type 2 frauds, why then are |
| 113 | they not enabled by default? Because they are defense-in-depth |
| 114 | measures, not the minimum sufficient measures needed to prevent |
| 115 | repository fraud in Fossil. Fossil provides its primary protections |
| 116 | through other means. |
| 117 | |
| 118 | Although you have complete control over the contents of your local |
| 119 | Fossil repository clone, you cannot perform Type 1 forgery on its |
| 120 | contents short of executing a [preimage attack][prei] on the hash |
| 121 | algorthm. ([SHA3-256][SHA-3] by default in the current version of |
| 122 | Fossil.) Even if you could, Fossil’s sync protocol will prevent the |
| 123 | modification from being pushed into another repository: the remote |
| 124 | Fossil instance says, “I’ve already got that one, thanks,” and |
| 125 | ignores the push. Thus, short of breaking into the remote server |
| 126 | and modifying the repository in place, you couldn’t even make use of |
| 127 | a preimage attack if you had that power. This is an attack on the |
| 128 | server itself, not on Fossil’s data structures, so while it is |
| 129 | useful to think through this problem, it is not helpful to answering |
| 130 | our questions here. |
| 131 | |
| 132 | The Fossil sync protocol also prevents the closest analog to Type 3 |
| 133 | frauds in Fossil: copying a commit manifest in your local repo clone |
| 134 | won’t result in a double-commit on sync. |
| 135 | |
| 136 | In the absence of digital signatures, Fossil’s [RBAC system][caps] |
| 137 | restricts Type 2 forgery to trusted committers. Thus once again |
| 138 | we’re reduced to an infosec problem, not a data structure design |
| 139 | question. (Inversely, enabling commit clearsigning is a good idea |
| 140 | if you have committers on your repo whom you don’t trust not to |
| 141 | commit Type 2 frauds. But let us be clear: your choice of setting |
| 142 | does not answer the question of whether Fossil is a blockchain.) |
| 143 | |
| 144 | If you’re wondering why Fossil’s current commit signing feature is |
| 145 | not enabled by default and why it doesn’t verify signatures on |
| 146 | commits, it is because Fossil is not itself a [PKI], and there is no |
| 147 | way for regular users of Fossil to link it to a PKI, since doing so |
| 148 | would likely result in an unwanted [PII] disclosure. There is no |
| 149 | email address in a Fossil commit manifest that you could use to |
| 150 | query one of the public PGP keyservers, for example. It therefore |
| 151 | becomes a local policy matter as to whether you even *want* to have |
| 152 | signatures, because they’re not without their downsides. |
| 153 | |
| 154 | 2. <a id="work"></a>**Work Contests.** Cryptocurrencies prevent forgery |
| 155 | by setting up some sort of contest that ensures that new coins can come |
| 156 | into existence only by doing some difficult work task. This “mining” |
| 157 | activity results in a coin that took considerable work to create, |
| 158 | which thus has economic value by being a) difficult to re-create, |
| 159 | and b) resistant to [debasement][dboc]. |
| 160 | |
| 161 | Fossil repositories are most often used to store the work product of |
| 162 | individuals, rather than cryptocoin mining machines. There is |
| 163 | generally no contest in trying to produce the most commits. There |
| 164 | may be an implicit contest to produce the “best” commits, but that |
| 165 | is a matter of project management, not something that can be |
| 166 | automatically mediated through objective measures. |
| 167 | |
| 168 | Incentives to commit to the repository come from outside of Fossil; |
| 169 | they are not inherent to its nature, as with cryptocurrencies. |
| 170 | Moreover, there is no useful sense in which we could say that one |
| 171 | commit “re-creates” another. Commits are generally products of |
| 172 | individual human intellect, thus necessarily unique in all but |
| 173 | trivial cases. This is foundational to copyright law. |
| 174 | |
| 175 | 3. <a id="lcr"></a>**Longest-Chain Rule.** Cryptocurrencies generally |
| 176 | need some way to distinguish which blocks are legitimate and which |
| 177 | not. They do this in part by identifying the linear chain with the |
| 178 | greatest cumulative [work time](#work) as the legitimate chain. All |
| 179 | blocks not on that linear chain are considered “orphans” and are |
| 180 | ignored by the cryptocurrency software. |
| 181 | |
| 182 | The closest we can come to that notion in Fossil is the default |
| 183 | “trunk” branch, but there’s nothing in Fossil that delegitimizes |
| 184 | other branches just because they’re shorter, nor is there any way in |
| 185 | Fossil to score the amount of work that went into a commit. Indeed, |
| 186 | [forks and branches][fb] are *valuable and desirable* things in |
| 187 | Fossil. |
| 188 | |
| 189 | This much is certain: Fossil is definitely not a cryptocurrency. Whether |
| 190 | this makes it “not a blockchain” is a subjective matter. |
| 191 | |
| 192 | [arh]: https://fossil-scm.org/fossil/doc/trunk/www/hooks.md |
| 193 | [bse]: https://www.researchgate.net/publication/311572122_What_is_Blockchain_a_Gentle_Introduction |
| 194 | [caps]: ./caps/ |
| 195 | [cs]: https://fossil-scm.org/home/help?cmd=clearsign |
| 196 | [dboc]: https://en.wikipedia.org/wiki/Debasement |
| 197 | [dsig]: https://en.wikipedia.org/wiki/Digital_signature |
| 198 | [fb]: https://fossil-scm.org/home/doc/trunk/www/branching.wiki |
| 199 | [GPG]: https://gnupg.org/ |
| 200 | [PGP]: https://www.openpgp.org/ |
| 201 | [PII]: https://en.wikipedia.org/wiki/Personal_data |
| 202 | [PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure |
| 203 | [pow]: https://en.wikipedia.org/wiki/Proof_of_work |
| 204 | [prei]: https://en.wikipedia.org/wiki/Preimage_attack |
| 205 | |
| 206 | |
| 207 | |
| 208 | ## Distributed Ledgers |
| 209 | |
| 210 | Cryptocurrencies are an instance of [distributed ledger technology][dlt]. If |
| 211 | we can convince ourselves that Fossil is also a distributed |
| 212 | ledger, then we might think of Fossil as at least a peer technology, |
| 213 | having at least some qualifications toward being considered a blockchain. |
| 214 | |
| 215 | A key tenet of DLT is that records be unmodifiable after they’re |
| 216 | committed to the ledger, which matches quite well with Fossil’s design |
| 217 | and everyday use cases. Fossil puts up multiple barriers to prevent |
| 218 | modification of existing records and injection of incorrect records. |
| 219 | |
| 220 | Yet, Fossil also has [purge] and [shunning][shun]. Doesn’t that mean |
| 221 | Fossil cannot be a distributed ledger? |
| 222 | |
| 223 | These features only remove existing commits from the repository. If you want a |
| 224 | currency analogy, they are ways to burn a paper bill or to melt a [fiat |
| 225 | coin][fc] down to slag. In a cryptocurrency, you can erase your “wallet” |
| 226 | file, effectively destroying money in a similar way. These features |
| 227 | do not permit forgery of either type described above: you can’t use them |
| 228 | to change the value of existing commits (Type 1) or add new commits to |
| 229 | the repository (Type 2). |
| 230 | |
| 231 | What if we removed those features from Fossil, creating an append-only |
| 232 | Fossil variant? Is it a DLT then? Arguably still not, because [today’s Fossil |
| 233 | is an AP-mode system][ctap] in the [CAP theorem][cap] sense, which means |
| 234 | there can be no guaranteed consensus on the content of the ledger at any |
| 235 | given time. If you had an AP-mode accounts receivable system, it could |
| 236 | have different bottom-line totals at different sites, because you’ve |
| 237 | cast away “C” to get AP-mode operation. |
| 238 | |
| 239 | Because of this, you could still not guarantee that the command “`fossil |
| 240 | info tip`” gives the same result everywhere. A CA or CP-mode Fossil |
| 241 | variant would guarantee that everyone got the same result. (Everyone not |
| 242 | partitioned away from the majority of the network at any rate, in the CP |
| 243 | case.) |
| 244 | |
| 245 | What are the prospects for CA-mode or CP-mode Fossil? [We don’t want |
| 246 | CA-mode Fossil][ctca], but [CP-mode could be useful][ctcp]. Until the latter |
| 247 | exists, this author believes Fossil is not a distributed ledger in a |
| 248 | technologically defensible sense. |
| 249 | |
| 250 | The most common technologies answering to the label “blockchain” are all |
| 251 | DLTs, so if Fossil is not a DLT, then it is not a blockchain in that |
| 252 | sense. |
| 253 | |
| 254 | [ctap]: ./cap-theorem.md#ap |
| 255 | [ctca]: ./cap-theorem.md#ca |
| 256 | [ctcp]: ./cap-theorem.md#cp |
| 257 | [cap]: https://en.wikipedia.org/wiki/CAP_theorem |
| 258 | [dlt]: https://en.wikipedia.org/wiki/Distributed_ledger |
| 259 | [DVCS]: https://en.wikipedia.org/wiki/Distributed_version_control |
| 260 | [fc]: https://en.wikipedia.org/wiki/Fiat_money |
| 261 | [purge]: /help?cmd=purge |
| @@ -250,11 +303,11 @@ | |
| 303 | since you can’t verify the proofs of these signatures if you can’t first |
| 304 | prove that the provided signatures belong to people you trust. This is a |
| 305 | notoriously hard problem in its own right. |
| 306 | |
| 307 | A future version of Fossil could instead provide consensus [in the CAP |
| 308 | sense][cacp]. For instance, you could say that if a quorum of servers |
| 309 | all have a given commit, it “belongs.” Fossil’s strong hashing tech |
| 310 | would mean that querying whether a given commit is part of the |
| 311 | “blockchain” would be as simple as going down the list of servers and |
| 312 | sending it an HTTP GET `/info` query for the artifact ID, returning |
| 313 | “Yes” once you get enough HTTP 200 status codes back. All of this is |
| @@ -275,16 +328,17 @@ | |
| 328 | doesn’t work to use a term in a nonstandard way just because you can |
| 329 | defend it. The people you’re communicating your ideas to must have the |
| 330 | same concept of the terms you use. |
| 331 | |
| 332 | |
| 333 | What term should you use instead? Fossil stores a DAG of hash-chained |
| 334 | commits, so an indisputably correct term is a [Merkle tree][mt], named |
| 335 | after [its inventor][drrm]. You could also use the more generic term |
| 336 | “hash tree.” |
| 337 | |
| 338 | Fossil is a technological peer to many common sorts of blockchain |
| 339 | technology. There is a lot of overlap in concepts and implementation |
| 340 | details, but when speaking of what most people understand as |
| 341 | “blockchain,” Fossil is not that. |
| 342 | |
| 343 | [drrm]: https://en.wikipedia.org/wiki/Ralph_Merkle |
| 344 | [mt]: https://en.wikipedia.org/wiki/Merkle_tree |
| 345 |