A few days ago my friend Mo and myself released the AKAP contract. This contract implements the AKA protocol, which only briefly is described as somewhat like LDAP for Ethereum.
That in itself doesn’t tell you much. Only the especially interested will read the whitepaper, and think about the possibilities. Instead, what’s needed is to make it practical or useful, in the form of tools and libraries.
While far from ready at the time of writing this, these tools and libraries are in the process of being developed. And when they’re at a usable stage I’ll put them on GitHub. But let’s first dive into some of the issues the AKAP contract can solve for us.
Immutability
If you’re an Ethereum blockchain developer you know that what you put on the ledger stays on the ledger. You deployed some contract, and now there’s no replace option available. That code will be there forever, exposing its API for anyone to see and play with.
There’s something fascinating about being able to deploy useful and functional code that will outlive you. But it’s also a bit frightening. Because as a developer you know that bugs are unavoidable in anything but the most simple of software.
In the whitepaper we go into some detail about the approach we took for AKAP. While there exists upgrade patterns in Ethereum, which I’ll cover below, they bring with them political and social risk. If I can update or change something you depend on, why would you depend on it? You might trust me enough right now to build on what I offer, but what about tomorrow? Or next year? Or in 10 years when my political views have changed sufficiently to no longer want you to benefit from my services?
Because AKAP is a registry we think there’s a network effect and benefit in having a shared central location in the form of the AKAP contract address. Instead of having everyone deploy their own registry we believe it is more beneficial to share one registry. We find similar network benefits on the Internet, with a shared DNS or IP address space, for example. To avoid anyone needing to trust us past what’s already in the open we opted for no upgrade patterns on AKAP. What’s there will be there forever, and no one can change that. Neither me, Mo, or anyone else. The nodes you create on AKAP remain yours for as long as you want them. They can never be censored or modified without your consent.
That of course also means that if there is a bug in AKAP we’re doomed. There’s no way to fix it. The whitepaper describes the approach we took to minimize this risk. And as time goes on we can accrue confidence in that decision.
Breaking immutability
While what I said about immutability above is true, i.e., the code you deploy will remain as is forever, I also mentioned upgrade patterns. So what are those?
While the code might be immutable, the state is not. And this is good because immutable state is only of limited use. And while it is generally considered good practice to separate code from state, sometimes we also need to mess with the code. On Ethereum you do this by deploying what’s called a proxy contract. You interact with the proxy, and the proxy pretends to be some other code. From your perspective it looks and feels just like it should, with the proxy providing all the code and functionality of the contract it’s fronting. The actual code being used is behind another address, and the proxy holds a reference to this address. This is how we can upgrade the functionality, because we can change the address.
What about storage? Just like we’ve separated code from location using a proxy, we’d like to separate storage from location as well. Eternal storage is a pattern which describes this, and AKAP very much caters to this sort of functionality, with some added benefits on top. We’ll help make these benefits obvious and easy to use with AKAP utils.