Not that I’d accuse anybody of paying attention, but quietly Karai Coordinator has been reaching 1.0.0 and I thought, “Where is that guy who writes the dev updates?” only to realize, “Oh shit, that’s me…”
Karai began as a promise to bring private smart contracts to TRTL. I can elaborate some other time about why it didn’t become smart contracts, but the gist of it is, Karai is a scaling tool that can be attached to any blockchain to form sidechain-like feeds of cryptographically linked events that can “check in” their state on any cryptocurrency blockchain.
Karai is not a cryptocurrency and has no native coin/token, and in order to prove that this thing works, it made sense to embed TRTL functions natively inside of Karai.
In the past, Karai shipped as a single app that had coordinator functions as well as client functions in the same app. As time went on it made more sense for them to both exist separately. Things continued a little bit further and I started to like the idea of keeping them apart.
Karai Coordinator is needed to create your channel, and must be running to process transactions. Coordinator acts as a centralized time stamping authority that assembles the graph of transactions. It also handles connections to the graph, with each user generating their own certificate to manage access.
Karai Reference Client is not so much a production app but more of a tool to test the functions on the coordinator, and for prospective app developers to see how you can interact with a coordinator. Incidentally, the reference client started out as an attempt to use libkarai-go which is the Karai library for Golang, however I kept iterating the development of it and eventually had replaced the library code and so now it functions as its own native client. shrug.
I ask myself a lot, “what’s all this for?”. Obviously nobody wanders around the Bitcoin circles saying “you know what this needs? Karai.” and they probably won’t… until I build a proof of concept that brings people in.
Last week I had the chance to do a 3 day weekend hackathon while the house was empty, and just for shits and giggles built a proof of stake cryptocurrency that runs on top of Karai. It has a daemon, wallet, api, post-quantum hashing algo, all the cool stuff an aspiring shitcoin artist would want. It was just a proof that it could be done, barring the invention of a ERC20 standard for TRTL, it will just sit in a private repo, but the fact remains, Karai has potential.
Nobody knows. It would be safe to say if you wanted to build a cryptocurrency today or a lightning fast scaling component to an existing network today, Karai is a ready made choice. If you wanted to take a privacy network like TurtleCoin, Monero, or ByteCoin and wanted lock some coins up and issue a non fungible token and create CryptoTurtles, theres nothing stopping you. Do I hope that Karai wont only be used to spawn more shitcoins? Only time may tell…
As Karai is starting to reach a stable state, here are some new things that will be occupying my nights & weekends:
If you think of TRTL or Bitcoin as a “blockchain” where there is a singlefile dotted line of blocks one after the other, Karai would be like a fractal web of transactions unconstrained by blocks. Karai has a graph, where TurtleCoin has a blockchain.
In the past, Karai has used the passing of time to store smaller graphs in big batches on the main graph, so as time moved forward Karai would pile transactions all into a subgraph, then wait for a lull in activity before creating a new subgraph. Recently this changed in a way that I think makes more sense.
The issue with lumping all transactions in a given time period into batches is that we are basically creating blocks, in a chain, effectively replacing our surroundings with where we came from; since the whole reason why we went with a DAG was to be more efficient, this felt backwards when we were able to visualize the data and watch it work. Scanning these blobs for what might be your transaction didnt seem like it would be a treat either.
Subgraphs 2.0 brought a new concept, borrowed from Nano/Raiblocks, where each user spawns their own subgraph, greatly reducing scan time for ingesting your own transactions, and with an added bonus of spam being a direct hinderance on the person creating it.
In SG1, when a user would add a transaction, it could be lumped with other transactions from other users before being arranged into a subgraph. The scan speed was shortened by using the first TX in a subgraph to store metadata about which users/pubkeys were present in the blocks descending from it.
On the whiteboard, this seemed like a great idea. In practice, however, comingling users into the same subgraphs made it tough because youd still be ingesting the entire subgraph and scanning for your transaction, it was difficult to segment the network in a way that made sense when you get paired up with a noisy neighbor.
In SG2, each user has their own subgraph that begins with the first transaction they send. Each transaction they send after directly follows their last transaction, so spamming transactions over and over only affects yourself, as when you join youre now fetching a subgraph based on your pubkey, and are only charged with scanning outside of your own subgraph when verifying the entire lineage of the entire graph, which is basically never. Instead of a blockchain, we now have a multifaceted helix, a strand of graphs/chains all flowing in parallel and tied at the end.
SG2 is live now, there are still some improvements that can be made, but in the mean time give it a shot. There are two staging networks. Ironically the one marked stable is least stable and operates on an outdated codebase still running SG1 if it is still running.
Small note for developers: Please make an issue before contributing a PR. The code in the Github repos is not the active development tip, development happens offsite on another Git service and gets dragged over to Github periodically.