cheng/wallet
0
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

done

Browse Source
This commit is contained in:
reaction.la 2022-04-14 02:19:37 -07:00
parent bec06a5dce
commit 84847ffdcd
No known key found for this signature in database
GPG Key ID: 99914792148C8388
2 changed files with 71 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

78
docs/merkle_patricia_dag.md
View File

@ -259,9 +259,11 @@ information from the peer that has the node with more children.
xmlns:xlink="http://www.w3.org/1999/xlink"
width="29em" height="18em"
viewBox="0 170 220 140"
style="background-color:ivory" stroke-width="1"
style="background-color:ivory"
stroke-width="1"
stroke-linecap="round" >
<!-- viewBox="0 186 220 129"
<!--
viewBox="0 170 220 140"
viewBox="10 216 100 59"
viewBox="70 192 100 59"
-->
@ -274,8 +276,8 @@ information from the peer that has the node with more children.
</text>
</g>
<path stroke="#0D0" fill="none" d="
M15,238 c28,-12 -12,18 -12,28 s6,1 7,0
M14,237 c40,-20 -19,34 6,18
M15,238 c28,-12 -12,20 -12,28 S10,271 9,265
M14,237 c29,-14 3,14 0,19 s6,3 6,-2
M13,236 c30,-22 10,18 28,2
M11,236 c30,-36 64,2 70,-14
M9,236 c24,-36 55,-28 84,-28 s70,6 70,-9
@ -399,7 +401,7 @@ x "/>
This data structure means that instead of having one gigantic
proof that takes weeks to evaluate that the entire blockchain is
valid, you have an enormous number of small proofs that each
particular part of the blockchain is valid. This has three huge
particular part of the blockchain is valid. This has three
advantages over the chain structure.
1. A huge problem with proof of stake is "nothing at stake".
@ -423,26 +425,32 @@ patricia dag to support immutability.
The intended usage is an immutable append only dag.
In a binary patricia tree each vertex has two links to other vertices,
one of which corresponds to appending a $0$ bit to the bitstring, and
one of which corresponds to adding a $1$ bit to the bitstring that
identifies a vertex and the path to the vertex
one of which corresponds to appending a $0$ bit to the bitstring that
identifies the vertex and the path to the vertex, and one of which
corresponds to adding a $1$ bit to the bitstring.
In this dag vertices that have bit strings ending in a $0$ bit have a
In this dag vertices identfied by bit strings ending in a $0$ bit have a
third link, that links to a vertex whose bit string is truncated back to
the previous $0$ bit, a shorter bitstring. Thus, whereas in blockchain
(Merkle chain) you need $n$ hashes to reach and prove data $n$ blocks
back, in this Merkle patricia dag, you only need $\bigcirc(\log_2n)$ hashes.
the previous $1$ bit, and that trailing $1$ bit zeroed, a shorter bitstring. Thus, whereas in blockchain (Merkle chain) you need $n$ hashes to
reach and prove data $n$ blocks back, in this Merkle patricia dag, you
only need $\bigcirc(\log_2n)$ hashes to reach any vertex of the blockdag.
The vertex $0010$ has an extra link back to the vertex $000$, the
vertices $0100$ and $010$ have extra links back to the vertex $00$, the
vertices $1000$, $100$, and $10$ have extra links back to the vertex $0,
and so on and so forth.
This enables clients to reach any previous vertex through a chain of
hashes, and thus means that each new item in sequence is a hash of
all previous data in the tree.
all previous data in the tree. Each new item has a hash
commitment to all previous items.
The clients keep the old roots of the balanced binary trees of blocks
around, so the peers cannot sodomize them. This will matter more
and more as the blockchain gets bigger, and bigger, resulting in ever
fewer peers with ever greater power and ever more clients, whose
interests are apt to be different from that of ever fewer and
ever greater and more powerful peers.
The clients keep the old roots of the balanced binary trees of
blocks around, so the peers cannot sodomize them. This will matter
more and more as the blockchain gets bigger, and bigger, resulting
in ever fewer peers with ever greater power and ever more clients,
whose interests are apt to be different from those of ever the fewer
and ever greater and more powerful peers.
The superstructure of balanced binary Merkle trees allows us to
verify any part of it with only $O(log)$ hashes, and thus to verify that
@ -478,10 +486,22 @@ ever growing oids.
When we defined the key for a Merkle patricia tree, the key
definition gave us the parent node with a key field in the middle of
its chilren, infix order
its chilren, infix order. For the tree depicted above, we want postfix order.
For this dag, we would like to define an oid field so that the oid
field of a parent follows the oid fields of its children.
Normally, if the bitstring is a full field width, the vertex contains the
information we actually care about, while if the bitstring is less than
the field width, it just contains hashes ensuring the data is
immutable, that the past consensus has not been changed
underneath us, so, regardless of how the data is actually physically
stored on disk, these belong in differnt sql tables.
So, the oid of a vertex that has a full field width sized bitstring is
simply that bitstring, while the oid of its parent vertices is obtained
by appending $1$ bits to pad the bitstring out to full field width, and
subtracting a count of the number of $1$ bits in the original bitstring,
`std::popcount`, which gives us sequential and ever increasing oids
for the parent vertices, if the leaf vertices, the vertices with full field
width bitstrings, are sequential and ever increasing..
Let us suppose the leaf nodes of the tree depicted above are fixed size $c$, and the interior vertices are fixed size $d$ ($d$ is probably thirty two or sixty four bytes) and they are being physically stored in
memory or a file in sequence.
@ -494,20 +514,6 @@ relationship to the bitstring of a vertex corresponding to a complete
field, which is the field that represents the meaning that we actually
care about).
We can calculate the location of an interior vertex from the number
of the largest numbered leaf node that it could be a parent of:\
To find the oid of a vertex accessed as an sql table pad its bitstring
out to the field width plus one with $1$ bits, (equivalent to
subtracting one from key and oring the result with the key) subtract
the `std::popcount` of the bitstring, and you have the sequential
and always incrementing oid, such that the oid of a parent is always
one greater than the oid of its right child.
If the field is an integer, the block height, the number of blocks in
the blockchain, the oid is one bit larger and approximately twice the
size of that integer, assuming that we are putting vertices and block
roots in the same sql table. (Which we probably won't.)
# Blockchain
A Merkle-patricia block chain represents *an immutable past and a constantly changing present*.

30
docs/writing_and_editing_documentation.md
View File

@ -247,6 +247,28 @@ through a narrow pass, in which case you are going to have a C
curve going to the narrow pass, and an S curve going to the
destination or the next narrow pass.
When you want to join two points, and don't care about the path, use an L straight line
When you want to join two points, and you care about the direction
in which it starts, or the direction in which it finishes, but not both,
use a Q, which gives you one degree of control freedom.
When you want to join two points, and care about the direction it
starts, and the direction it ends, use a C, which gives you two
degrees of control freedom.
When you want to join two points, and care about the direction it
starts, the direction it ends, and you want it to go through a
gateway in the middle, use a C S, which gives you three degrees
of control freedom. But watch out for the reflection of the last control
point in the C landing somewhere difficult inside the S curve. If the last control point in the C is further from the end point of the C
than the end point of the S, things can get strange. Sometimes you
want to adjust the behavior of the S curve by moving the last
control point of the previous C or S to the right position. A distant
previous control point is apt to have a big effect on the following S,
a near control point little effect, but likely to give you an
unpleasantly sharp turn at the join.
``` default
M point c point point point s point point
s point point ... s point
@ -256,8 +278,8 @@ Is guaranteed to give you a smooth curve, for reasonably sane
control points, with the curve passing through the second point of
the s, and its direction set by the first point of the s.
You change a point, the effect is entirely local, does not propagate
up and down the line.
You change a control point, the effect is entirely local, does not
propagate up and down the line.
``` default
M point q point point t point t point ... t point
@ -269,7 +291,9 @@ of the t points, but you cannot easily control the direction the curve
takes through the points. Changing the control point of the first q
will result in things snaking all down the line, and changing any of
the intermediate t points will change the the direction the curve
takes through all subsequent t points.
takes through all subsequent t points, sometimes pushing the curve
into pathological territory where bezier curves give unexpected and
nasty results.
Scalable vector graphics are dimensionless, and the `<svg>` tag's
height, width, and ViewBox properties translate the dimensionless