The past week has been a fun one as I’ve started trying to actually write some ethereum code and figure out if the eco-system is ready for me to try to build on top of yet. My very high-level priorities are currently:

Figure out if I can build a decaying currency as prescribed by hypercatallaxy on ethereum.
Figure out how to integrate this system with existing payment networks in a way that gives the Catallax card an unfair advantage over other kinds of payment networks.
Figure out how to build the governance model as described in my book “Immortality” on the ethereum blockchain.
Figure out how to transition from a “benevolent dictator” model to the created governance model in a trustless way that makes sense for system stability.

This week was all about #1. I don’t have any code to post yet, but I did make some significant discoveries that I think will be productive:

Ethereum transactions are expensive.

They are not as expensive as bitcoin transactions, but still expensive enough that building out all the infrastructure in blockchain storage is just not really an option at this point. Writing a piece of data (address-> unit) looks like it can cost about $0.008. This is not that bad unless you are catching up and trying to send a couple dollars of demurrage to the 10,000 accounts that in your pref table. Then all of a sudden you are updating 10,000 address -> uint pairs and this is going to cost you $80 to distribute $2 in decay. This obviously won’t work right now. Moore’s law says this probably won’t work for 12 years if gas costs track computing power.

Storing Data Off Chain

The solution looks like it may be storing data off chain. Your pref map and even your balance may end up needing to be off chain in some trustless data structure. TrueBit looks like the leader in the clubhouse here. Because of the way hypercatallaxy works we should be able to structure code in such a way that current balances are deterministic given a set of transaction operators. TrueBit lets any number of solvers run our code for us and update the blockchain. If they try to lie, verifiers can force them to prove their calculations and take a large reward if they catch a cheater. There are a bunch of things to work through here, but my current thoughts are that the Ethereum based part of the problem may end up just being a linked list of structs that track:

transactionType: uint (these will be coded in solidity based code so EVMs can run the transactions)

transactionHash: byte32 (this is a signature proving that the msg.sender created the transaction)

transactionLocation: byte32 (this is an ipfs hash pointing to a location where the json of the transaction detail can be publicly retrieved and verified with the has

I’ve just started thinking through this so there may be some more variable needed, but this kind of structure should get recording transaction down to a few cents and that is way more manageable.

If you have any insight or sample projects that have done this kind of structure where most of the data is kept off chain, let me know where to look. Source code is a super bonus.

Next Steps:

I think I’m going to be learning a lot about Merkle Trees and roots and how those can be recorded once and then used as verification.

I’m also meeting with a card processing company that may have some insight on how I can set up goal #2. If nothing else I’ll have some expectation of the costs involved and be able to do some of the math necessary to figure out if the 0 transaction fee is going to be feasible or not.

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0