In this post, I'm going to talk a bit about my progress on the WEn3 Web 3.0 Entropy layer in the coinZdense project, and the so far experimental code for moving the coinZdense application-RC to a new YAML based format.
coinZdense
For those who don't know about the coinZdense project, it is a rather big (currently) one-man project aiming to create a multi-language (Python, C++(17), JavaScript, Monte, Rust, Clojure, ClojureScript and possibly Go, Elixir, TypeScript and PyScript) collection of compatible signing libraries. The project, as desctibed in a previous blog post,aims to be a least-authority hash-based-signing and sub-key management layer for the post-quantum version of Web 3.0.
It may be interesting to note that coinZdense as a project is a spin-off of my speculative fiction novel Ragnarok Conspiracy, a novel, originaly published on HIVE (then named steemit), that may very well (please correct me if I'm wrong) the world's very first WEB-3.0-first published novel.
Now, to my knowledge, the coinZdense project might be in the process of becoming the world's first open-source project that is a spin-off of a work of fiction.
YAML application-RC
In my last blog post I talked about the new YAML format. An earlier version of the application-RC was a JSON based file format and was quite a bit more rigid in its expressability. Before we can understand what the application-RC files are all about, we need to understand two details about the design of coinZdense. The first detail is that coinZdense tries to adhere to the Principle Of Least Authority (POLA) when it comes to signing key authority and sub-key management. The coinZdense sub-key management is all about decomposition and recomposition in a least-authority way.
A second design detail for coinZdense centers around the pivotal role of the concept of entropy as a resource. The project builds on libsodium that provides functionality for Deriving keys from a single high-entropy key. The use of this functionality creates an entropy pool for coinZdense, that within the project is managed as a resourc. A resource that is also managed acording to the Principle Of Least Authority.
Now comes the application-RC that weaves these two design details together. The application-RC defines the Web 3.0 usage and allocation strategy of the whole entropy index-space provided by the mentioned libsodium functionality.
If a Web 3.0 project wants to use coinZdense, it needs to write and dimension an application-RC file that defines how the Web 3.0 project aims to use the Web 3,0 Entropy space.
WEn3 (Web 3.0 Entropy)
Since writing my last blog post, I've been experimenting with some Python code that hasn't yet been made part of the under-construction library yet. I'll be moving this code into the main Python codebase for coinZdense soon. This code is the first implementation of the coinZdense WEn3 layer that includes both the interpretation and usage of the application-RC files and the implementation of least authority sub-key management and the least-authority implementation of resource management on the actual index space for the Web 3.0 Entropy pool.
WEn3, a pun on Web 3.0 and Entropy, pronounced using the basically the dutch pronountiation of the number 3 (drie) with some extra emphasis on the R. Or to say it differently, it is pronounced like the name Wendy, the name of someone really special to me , but with a roling R folowing the D.
So let's revisit. We have a yaml application RC looking something like this:
---
appname: HIVEISH
hashlen: 32
otsbits: 5
heights:
- 9
- 9
- 8
subkeys:
- typ: default
shared: 4096
heights:
- 6
- 6
- name: ACTIVE
allocated: 38
heights:
- 9
- 9
- 8
subkeys:
- typ: default
allocated: 0
shared: 4096
- name: POSTING
allocated: 128
shared: 4096
subkeys:
- typ: default
allocated: 0
shared: 4096
heights:
- 6
- 6
- name: vote
- name: comment
- name: transfer
- name: recover_account
This application-RC defines a coinZdense application named HIVEISH (that as the name suggests is modeled loosely on HIVE). The unnamed unatenuated account level key (that in HIVE would be named the OWNER key) uses 32 byte long hashes as primitive, and signs such a 32 byte (256 bits) hashes in chunks of 5 bits (that is, 52 chunks per signature). It is a three level signing key with level key height attributes of respectively 9 bits, 9 bits and 8 bits.
This OWNER or account key will allocate a small part of the available WEn3 space, the rest of the 2⁶⁴ entries in the WEn3 space are considered to be free heap space untill sub-keys are allocated.
Now, when the OWNER key is used to sign a transaction, that will happen in the pre-allocated WEn3 space where just a number will be incremented. WEn3 is designed so that it is possible for application designers to allow new sub-keys to be created after the key gets too exausted to sign transactions. This is done by reserving the first chunk of the total signing space.
The allocated key in the above application-RC is used to indirectly set the number for reserved signatures. For example we define that we want to be able to still sign 32 ACTIVE keys from reserved signature space when the non-reserved signature space gets exausted. Later on that we want to be able to allocate at least 128 POSTING keys from within every ACTIVE key. Note that there are no individual quotas on sub-keys of different types. The reserved space gets all added up,and there is nothing stopping one subkey type from eating up more reserved space than defined in the application-RC.
This is not the only impact of the allocated key, together with the shared key, the allocated key determines the amount of extra heap the creation of a subkey will claim. Look at it this way
- allocated: allocate this much extra heap
- shared: allocate only the largest shared claim at this level.
Let's say transfers would reserve 100 and share 1000, and POSTINGs would reserve 250 and share 500, then the combintion within ACTIVE would reserve 350 and allocate 1000, resulting in a net reservation of 1350 chunks of WEn3 space.
Yes, it's a bit complicated, but when you start playing with it you'll quickly get a feeling for it.
Local serialization
So let's look at a tiny bit of code showing the use in our current code:
# First make our var dir, this should get its own class in the library
owndir = os.path.join(os.path.expanduser("~"), ".coinzdense")
if not os.path.exists(owndir):
os.mkdir(owndir)
vardir = os.path.join(owndir,"var")
# Load the yaml file
with open("etc/coinzdense.d/hiveish.yml", encoding="utf8") as apprc:
data = load(apprc, Loader=Loader)
# Create the WEn3 KeySpace subkey
owner_key = KsSubKey(RcSubKey(data, minimum=20.0), statedir=vardir, account="silentbot")
# Get some indices for signing transactions
print(owner_key.signing_index())
print(owner_key.signing_index())
print(owner_key.signing_index())
print(owner_key.signing_index())
print(owner_key.signing_index())
# Derive two ACTIVE subkeys
active1 = owner_key["ACTIVE"]
active2 = owner_key["ACTIVE"]
# Give the second ACTIVE key a non standard pet-name
active2.set_petname("SPARE_ACTIVE")
We create a WEn3 environment from the hivish.yml application-RC file, that we than use to create subkey allocation object for the OWNER key that we link to on-disk serialization for the @silentbot account.
We then start asking for a few transaction signing indexes (that the signing layer will use),and allocate two subkeys.Finaly we set a petname for one of the newly created sub-keys for easy access.
The above code will create the following file in the file-system that it will sync to on every operation.
~/.coinzdense/HIVEISH/wen3/silentbot.json
I ran a test with asomewhat larger application RC, and the resulting serialization currently looks something like this:
{
"keys": {
"-1": {
"keyspace_offset": 0,
"keyspace_end_offset": 18446744073709551615,
"heap_offset": 7141643777,
"reserved_index": 0,
"regular_index": 45,
"heap_pointer": 16997384384665681035,
"parent_sign_index": -1,
"node": [
"HIVEISH"
]
},
"43": {
"keyspace_offset": 7141643777,
"keyspace_end_offset": 8498692195903662405,
"heap_offset": 14283287554,
"reserved_index": 0,
"regular_index": 128,
"heap_pointer": 14283287554,
"parent_sign_index": 43,
"node": [
"HIVEISH",
"ACTIVE"
]
},
"44": {
"keyspace_offset": 8498692195903662406,
"keyspace_end_offset": 16997384384665681034,
"heap_offset": 8498692203045306183,
"reserved_index": 0,
"regular_index": 128,
"heap_pointer": 8498692203045306183,
"parent_sign_index": 44,
"node": [
"HIVEISH",
"ACTIVE"
]
}
},
"petnames": {
"HIVEISH": "-1",
"ACTIVE-43": "43",
"SPARE_ACTIVE": "44"
}
}
Discussing all the fields in this state file falls outside of the scope of this blog post. The idea is that this file contains all relevant WEn3 data that is needed to continue using the WEn3 layer the next time we use these keys. That is, at least when we use the sub-keys in the way coinZdense intends them to be used. More on that in the next section.
On-chain state
The state files above will normally work just fine if there is just one client using one subkey, but chances are this will not always be the way things will actualy be used by everyone. When there are two clients using the same key, we should be able to recover from out-of-sync state files.
The way we do this is by the requirement that the blockchain remembers a few numbers about the last signed operation with every subkey. These numbers are:
- reserved_index
- regular_index
- heap_pointer
Currently some design chanches will be needed for including this info in relevant signatures.
What's next?
One thing that is currently still missing from the WEn3 layer test code is revocation. Revocation is going to be WEn3 based in that we will be revoking WEn3 space, not individual sub-keys. This feature might end up requiring some design chanches, so we need working revocation demo code first before we start integrating the WEn3 code into the library
I'll do an other blog post as soon as I have working demo code and some solid ideas about integration into coinZdense.
Help make this project a success
As stated, coinZdense is a rather large and currently one-man project. It is also a project that currently has zero funding. I want to allocate a lot of time on this project because it is important for the future of Wen 3.0 projects such as HIVE, but I can't do it alone. I need community support.I currently don't need other developers to help out, that day will come, but first I need to finish a complete reference implementation in both Python and (probably) C++.
Talk about this project
If you understand the importance of this project for the future of Web 3.0 projects, then even if you can't help me our with your technical skills or by helping me fund my time, you can still help by being an advocate for the project. Talk about coinZdense, blog about coinZdense,spread the word. Some of the people who hear about the project because of you will donate to it, help out with it, or maybe also start advocating for it. My own time is best spent on developing, so anyone who can help me out by allowing me not to spent time I could be designing, coding, testing on having to advocate (with my horrible Dutch accent), your contribution would be so massively valuable.
Talk abour coinZdense. Talk about Ragnarok Conspiracy (my mostly FREE novel that is now basically marketing for coinZdense). Talk about how cool WEn3 is as a concept. About how important being reqdy for quantum computing is going to be for Web 3.0 in the future. Spread the word.
Help fund this project
There is a second way to support this project. Help fund my time, and (towards the future) the time of other developers. If you are on HIVE, upvote project posts like this one, send some $HIVE or $HBD to @croupierbor, and/or buy COINZDENSE project support tokens on hive-engine/tribaldex.
If you aren't on HIVE but want to donate other crypto such as Bitcoin, Bitcoin Cash, Ethereum, QRL, Zcash, Dogecoin, Litecoin, Dash, Digibyte or PolkaDot, go to my tipping jar and donate some crypto.
If you don't have any of these crypro coins either, you can also donate using PayPal
Help the project website suck less
I'm a multidiciplinary engineer, a novelist, and a few more things, but two thing that I'm not are a logo designer and a HTML guru. As a result the project website looks like it's bleeding 20 years old and made by a colour blind honeybadger. If you have some decent HTML/CSS skills and think you could help create a version of the project site that looks like its from 2022, and gives up a vibe in line with the Web3 and post-quantum nature of the project, then please, please, please come and help me out.
Ideas for an affiliates system?
Not sure if it would be possible, or reasonable to want, but if you have any ideas on how maybe an affiliate system could be set up for this project, so that, maybe 10% of donations can go to affiliate advocates, I'm all ears.
Ideas for COINZDENSE owner perks?
Right now the COINZDENSE project-support tokens are pretty much useless to the buyer. It might be interesting to see if there are any posibilities for coming up with future perks for COINZDENSE hive-engine tokens. If you have any insights in this, please drop me a comment.
Future project lead for ternary languages and devs for secondary languages
Right now the project doesn't need other developers. In four to six months though, I hope to have a reference implemention in Python and C++, and at that point in time porting to secondary languages and ternary languages will become important. I think I should be project lead on the secondary languages, but given my skill levels, not the ternary languages. If you are interested in contributing as a dev to the future JavaScript, Rust, Clojure or ClosureScript code or as a project lead to Go, Elixir or TypeScript, drop me a message so we can talk.
Small steps
The project is progressing again. Small steps for now, but the new WEn3 layer is really starting to take shape now. For now I'm throwing hours at this project without any real prospect on either structural funding or decently sized one-time donations that could fund my and other developers in completing this project. I need your help, your support, your advocacy to help make this project a success.