(Draft 1)
The concept of sidechain is defined in the whitepaper
The goal of this note is to explore the consequences of that definition, in particular as applied to my domestic furniture.
One thing that can be deduced from the introduction and other parts of the paper is that each sidechain C' is supposed to be designed, implemented, and managed by a separate group of developers (a dev team), who do not necessarily know or control the protocol of any other sidechain C'' that exchanges value with C'.
In particular, the dev team of C' will not know anything about the nature and identity of the users of C'', not how they can demonstrate and exercise control over the assets of C''. Moreover, the dev team of C' will be unable to determine whether the implementation of C'' is indeed consistent with the information provided by its dev team; and vice-versa. These assumptions -- independent development, and mutual knowledge that is incomplete and unreliable -- severly limit the guarantees that one may demand or provide about asset transfers.
Moreover, reading the paper it struck me that the concept of sidechain is not actually defined. The paper does not seem to clearly state any non-trivial feature that a sidechain must have, or must not have. Indeed, most of the key concepts used in the definition of sidechain (such as "asset", "control", "user", etc.) are not defined in the paper.
Considering the number and competence of the authors, it is unlikely that the lacunes in the definitions are the result of oversight. I must assume that the definitions were left vague on purpose, in order to allow maximum freedom to the designers of sidechains.
Well, that goal certainly was achieved: I believe that anything can satisfy the definition of a sidechain, by appropriate definition of the undefined concepts (which seem to allow even trivial or vacuous definitions). For example, any exchange, like Bitstamp, is a sidechain. Litecoin, together with any BTC-LTC exchange, is a sidechain.
Heck, even the old sofa in my living room is a sidechain. Which I proceed to demonstrate in the remainder of this note.
First, I must apologize for not providing evidence that I do have a living room and that there is indeed an old sofa in it. The image bove is not my sofa, of course, but only a digital image, an abstract pattern of bits.
However, sidechains too are just patterns of bits with certain properties. They do not need to exist in the material sense of the word, anywhere in the universe's spacetime, but only in the mathematical sense, in the same sense that all the infintely many integers exist, and the square root of minus one exists. Therefore, the material existence of my old sofa does not need to be established: the digital image above can be considered to be my sofa.
The definitions of sidechain and related concepts are given in section 3.1 of the paper. Starting from the root concept:
The paper does not define the concept of "transaction" anywhere, although it requires some properties of transactions that are constituents of a block. Therefore, we can consider that my sofa (denoted henceforth by S) is a transaction, by definition; and check those properties when we get there.
| S = |  |
A block is defined thusly in section 3.1:
Let B be the collection consisting of one element only, my sofa itself; that is,
| B = { S } = { | | } |
According to the previous section, S is a transaction, therefore, B is a collection of transactions.
To verify the condition "describing ..." in definition (1), we must consider the definition of "asset":
Again, the terms "digital property", "controller", and "ascertain" are not defined.
The term "property" (or "ownership") has an established legal definition, but it pressuposes an authority that keeps track of who owns what, defines the laws or rules for transfer of property, and enforces the property by returning possession or control of the item to the owner, by force if appropriate, if someone else tkes control of it in disaccord with those laws. Surely that is not the sense intended by the paper written by and for anarchists and libertarians. Therefore I presume that the word "property" there simply means "artifact".
For my sofa, the relevant digital artifact is the integer 418 in 16-bit unsigned binary notation. Its controller, by definition, is the real number sqrt(pi); a fact that can be trivially ascertained by any cryptographic method. So, the integer 418 is an asset, by definition (2).
Since the control of sqrt(pi) over 418 is permanent by definition, there are no changes in asset control. Therefore, the colection B = { S } obviously and vacuously describes the changes in asset control. Thus we have established that B is a block.
Let C be the collection that consists of the single block B defined in the previous section; that is,
| C = { B } = { { | | } } |
In section 3.1 of the whitepaper we find the definition
The collection C, having a single element, is obviously well-ordered, and in fact admits a single well-defined well-order. We only need to verify that it satisfied the condition "on which all users..."
The paper does not define "user". This is one point where the authors must have been intentionally vague, in order to allow the proponents of each sidechain to define "user" as it suits them. In the case of my sofa, there is no registry or users, or explicit designation or licensing requirement for its users (just as there are none for users, holders, and miners of bitcoin). For all intents and purposes, the users of my sofa must be defined as the people who happen to be sitting on it at any given time.
The paper also does not define "consensus" and what it means for "all users to come to consensus" on a blockchain. Perhaps one can stretch the etymology quite a bit and derive "consensus" from Latin "con" = "with" and "sedere" = "to sit", in which case "to come to consensus on" could mean "to show up and sit together on". Then it is obviously true that the users of my sofa always come to consensus on it.
That completes the proof that my old sofa is a blockchain, as defined in the paper. Note that the definition does not specify a minimum cardinality for a blockchain, nor that it should grow with time.
Actually, I could have simplified the proof above by defining the set of users of my old sofa to be empty, and defining the people sitting on it as "miners". In that case, the condition "on which all users..." would be vacuously satisfied. But some people find that proofs by vacuity are cheating.
After defining the concept of blockchain, the paper claims that
This claim is stated without any proof, and the concept "computationally unforgeable" is not defined. It is also unclear whether the word "This" refers to the blockchain, or to the condition "on which all users..." of definition (3). Without loss of generality, I will assume the former.
Note that my old sofa definitely "determines the history of asset control", since the history is empty, and "provides a time ordering for transactions" since there is only one transaction. The question remains whether the ordering is "computationally unforgeable", but since a singleton set admits only one ordering, it seems difficult to replace the true ordering by a false one.
So that claim seems to be true for my sofa at least. The authors should either prove that it is true for all sidechains, or remove that claim from the paper.
Anyway, the claim does not seem relevant for the task of establishing whether something is a blockchain or not.
We can now return to the main defintion:
The paper does not define "data" and how it can be extracted from a blockchain. Given the assumption that blockchains "are free to experiment with new transaction designs, trust models, economic models, asset issuance semantics, or cryptographic features" (p.7), that the "other blockchains" in definition (4) are not restricted to some specific subset of all possible blockchains, and that there is a countable infinitude of algorithms that can extract data from a blockchain, we must conclude that the "data" can be any finite binary string, and that a sidechain must be prepared to validate any such string.
Fortunately, the paper also does not define what "validate" means, so the proponents of a sidechain presumably are free to define that concept too, as it suits them. I will therefore assume that, in the case of my sofa, validation of data from other blockchains consists in applying to said data the function that, given any finite bit string, returns the logical value "yes". My old sofa obviously can do that: being inert, it has only one output state, that represents "yes" by convention.
I have thus established that the collection C = { { S } }, where S is my old sofa, is a sidechain.
Note that the definition of a blockchain or sidechain does not require the existence of a protocol for modifying it, or of a specific computing network or facility to execute such a protocol. Thus the definitions allow for static sidechains whose blockchains do not grow of change, like my old sofa. On the other hand, the definition does not require the transactions and blocks to be immutable; and allows arbitrary changes in the collection of blocks, and in its "time ordering".
Besides defining what a sidechain is in section 3.1, the paper also states (on pages 5-6) six requirements that are "desired properties" for a sidechain that aspires to be pegged.
These requirements are clearly not part of the definition of sidechain, so they do not impact on the conclusion of the previous section. Yet it turns out that mt old sofa S -- more precisely, the sidechain C = { { S } } -- does satisfy them.
Let's first review the six requirements and try to understand them.
I am assuming that "move" is synonymous with "transfer", even though neither term is defined. I am also assuming that "holder" is the same as "controller" as (not) defined in section 3.1, in the definition of asset (2).
The word "dishonest" is not defined. It would seem that its meaning is crucial, since, taken literally, this requirement would not be violated if a honest party was able to prevent the transfer from occurring. But since it would impractical for a distributed algorithm to ascertain whether an interfering party did or did not cheat on his/her/its significant other, it seems reasonable to assume that "dishonest party" was intended to mean simply "any party other than the controller of the asset".
The concept of "loss of assets" is not defined. When the assets are transferred, control presumably is transferred from some controlling entity associated with the first blockchain (possibly one of its "users", whatever that means) to some controlling entity associated with the sidechain (possibly one of "users"). My best guess as to what the authors understand as "loss of assets" in a transfer is that the second entity does not exist, or disappears right after the transfer; and that there is no mechanism in the sidechain to give control of them to some other controlling entity.
Note that that requirements [1], [2], and [3] are not about sidechains themselves, but about transfers between a blockchain C' and a sidechain C''. It is not stated clearly here, but from other parts of the paper one infers that such transfers require the cooperation of the entities that are mantaining the two blockchains. That in turn implies some super-protocol or superstructure that defines which pairs of blockchains can undertake such transfers and how they do it, and any communication channels that may be needed to execute the transfers.
Interestingly, this statement implies that the sidechain C'' may not be secure even against asset creation; and yet that will not ipso facto disqualify it from being a sidechain.
Here the authors seem to be overextending their reach, by implying that sidechains use the same methods of the bitcoin blockchain (proof-of-work by anonymous miners, with imperfect communication and heaviest-chain-wins rule). That seems to contradict the premise that sidechains are meant to experiment with innovative approaches.
As in most of the paper, this "definition" of reorganization is not a real definition, and is totally sloppy in its use of words. For "chain" they must meant "branch", of course; and for "client" they may have meant "sidechain". Moreover, it is not clear how a piece of table cutlery could possibly have a "losing side", and in fact what it has to do with the topic.
The paper again does not define the meaning of "track" and "actively use". (Would just holding assets in a sidechain count as "active use"? Would receiving assets into one's account count?)
It should be noted that, by these requirements, any altcoin or off-line payment processor is a good sidechain of the Bitcoin blockchain. With the commonly accepted notion of "asset" (bitcoins) and "control" (knowledge of the private key of the address where the bitcons currently are), requirements [4], [5], and [6] are guaranteed by the bitcoin protocol, and requirements [1], [2], and [3] are satisfied if the pegs are implemented with ordinary bitcoin transactions. Specifically, "moving an asset from the Bitcoin blockchain to the sidechain" and "moving the asset back" can be implemented as transactions that move BTC to and from bitcoin addresses whose private keys are known and managed by whoever or whatever is managing the sidechain. Then requirements 1, 2, and 3 are simply properties of the bitcoin protocol.
So, does my old sofa satisfy these requirements? Recall that its only asset is the integer 418 in 16-bit unsigned binary notation, permanently controlled by the real number sqrt(pi). Since no assets are ever moved from the bitcoin blockchain to my sofa, requirements [1]--[3] are vacuously true.
As for requirement [4], my sofa may have bugs, such as mites, spiders, or maybe even fleas. However, I have found no evidence on the web that such invertebrates have the power to cause theft of anything, much less theft of digital assets on other sidechains.
Requirement [5] too is satisfied, because the only operations that my sofa could undergo that may deserve to be called "reorganizations" are swapping or rotating the seat cushions; but experiments have shown that such moves (that, in fact, do not require a fork) do not cause any disruption on the bitcoin blockchain, or on any other sofa. In fact, moving the cusions does not cause the chain C'' (my sofa) to overtake or be overtaken by some other sofa or whatever.
Finally, for requirement [6], I can personally couch vouch that I have never required the users of my sofa to track the bitcoin blockchain or any other sidechain; and I trust that the development teams of other sidechains will not require their users to track my sofa.
As shown above, my old sofa (whether it exists or not) is not only a sidechain, but in fact a good sidechain.
Jorge Stolfi
March 07, 2016
-
Image originals (except my sofa) from the Wikimedia Commons