Regarding V

In this post I would like to address a few related aspects of v: why v, what is v, where does v come from, and what does v do.

The idea of v, the republican versioning system, transcends any single implementation. It is a whole new paradigm for the development and use of software. The underlying idea of v is to know completely the state of a piece of software, to be able to control all changes to it, and to ultimately know who is putting what changes into it. V allows one to confidently build code, know where it came from, and know it will not change unexpectedly1.

In the past, software development could be done by applying a series of patches to arrive at a final program state. With v, the patch is replaced with the slightly different vpatch, as described below. A collection of related of patches is referred to as a "v tree". A patch that only introduces new files is referred to as a "genesis".

One of the guiding principles behind the use of v is that each and every line should have a person to "blame", it should be obvious who wrote a line and who approved it. You can trace each line in a final document back by locating it in the corresponding vpatch and seeing who signed that vpatch. As Asciilifeform explained in a one line summary of vtronics: "every line has a sworn and cryptoauthenticated author".

The fundamental information provided in a vpatch is the state before the change, the change to the document (usually software code, but this system could be applied to any document), and the state after the change. The big change from old style patches to vpatches is that states are now given as cryptographic hashes2 of the document3 as found and as changed. Each vpatch is cryptographically signed by the author or approver4. Each time v is used it is run against a set of web-of-trust (WOT) identities (gpg keys), and only patches that have been signed by at least one of those identities will be included.

A v program is handy in that it automates a series of steps, but these steps can be done manually: 1. Each patch is verified with its corresponding signature, and the signer is verified to be within the WOT5. 2. The order of patches is determined by comparing "before" and "after" hashes for the files. 3.a. A patch is applied. 3.b. After applying the patch, the state is checked to verify that the patch applied as expected6. Repeat 3.a and 3.b until all patches have been applied.

It is not too hard to come up with a scenario that creates a diverging tree. The obvious way a tree can diverge is if two patches each alter the same file. Since v enforces changes to files based on their hash identity, if the two patches list the same hash as the starting point then only one can be used, as the other would no longer have the same hash-id'ed file to start with. A more subtle branching can also be made, where patches affect different files, and this can be non-dependent or soft-dependent. If two patches make unrelated changes in two different files then they are non-dependent on each other - the patches can be applied in either order. However, there could also be a dependency of one patch on the other. For example, a function could be defined in one file in the first patch, and the function could be called in a separate file in the second patch. In this case the program will build if the first patch is applied, but will not build if only the second patch is applied since the function would be missing its definition. This issue was addressed by adding a "manifest" file, which allows the enforcement of patch ordering over the whole set of files.

Ideally, each vpatch contains the changes of a single item - it should follow the ideal of "fits in head". The changes introduced could affect just one file or every file, but there should be some unifying theme that connects all the changes included.

Other references:
V for Victory
V-tronics 101
A collection of vpatch trees, for example, can be seen at

  1. Have you ever had a piece of software get "upgraded" and then everything which depends on it no longer works? Very frustrating. []
  2. When v was initially introduced the hash used was SHA-512, this was later changed to Keccak. []
  3. In the pre-v world, it was assumed that each person could have a different version of a file to apply a patch to, and so patch programs were made to be forgiving, and would try to find the best way to apply a patch. There are a number of ways this could go wrong. []
  4. Why would you not use the signature of the author? It is not possible to know everybody, and so the web of trust can help make decisions about who to trust. But maybe the author is too far away from you in this web, or perhaps he is not even in the web, and so you would instead rely on the signature of somebody who you did trust that read the vpatch and gives their signature of approval. In the strictest use of v the only key given to v is your own, and you only build software that you have personally read and signed. []
  5. The WOT here refers to the subset of identities which you have chosen to trust for changing this document, not the WOT as a whole. []
  6. The hash listed in the vpatch must match the hash of the file after the patch was applied. []

Tags: , , ,

Leave a Reply

MANDATORY: Adding 23 68 = ?
Answer before clicking "Submit", or comment will be discarded!