Karai Is Born
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…”
What is Karai, again?
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.
What does this have to do with TurtleCoin?
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.
A tale of two repos
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.
Libraries
-
libkarai-go
This library might work, and it might not. I refactored
it mid way through writing the reference client, so as
far as I can remember it should
work, but I cant say that without squinting a little bit
and wiggling my hand in a maaaaybeee
kind of way. If it does not work, or if it gives
inconsistent results, make an issue on Github and I will
fix it.
-
libkarai-js
This almost certainly will not work. It has not been
touched in quite some time.
-
libkarai-rs
A friend who writes Rust code said he would port the
library, however I havent bugged him in a while about it
(madk if youre reading this, this is you)
-
Other languages
I go through phases of wanting to learn other languages
for the purposes of writing libkarai in that language.
This seems to quickly reach a barrier though, in that I
have no idea which languages would be the most useful to
write a library in, and also, none of the languages I
want to learn are very popular at all. Some candidates
are/were Crystal, V lang, Nim, LISP.
What is next?
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.
What does this mean?
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…
Some ideas for now…
As Karai is starting to reach a stable state, here are some
new things that will be occupying my nights &
weekends:
-
better integration with TRTL Daemon + Wallet API
(urgent)
- karai-client browser plugin (nice to have)
-
TRTL as a staked asset for nonfungible token
(cryptoturtles is cool, but not essential)
- visualizing subgraphs
Some recent changes
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.
How does Subgraphs 2.0 fight spam?
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.
Give it a shot
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.
Karai Explorer - https://karai.io/explore
Icarus (Unstable) - http://167.71.104.172:4200/api/v1/stats
Daedalus (Stable) - http://46.101.200.220:4200/api/v1/stats
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.
Karai Is Born
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…”
What is Karai, again?
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.
What does this have to do with TurtleCoin?
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.
A tale of two repos
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.
Libraries
This library might work, and it might not. I refactored it mid way through writing the reference client, so as far as I can remember it should work, but I cant say that without squinting a little bit and wiggling my hand in a maaaaybeee kind of way. If it does not work, or if it gives inconsistent results, make an issue on Github and I will fix it.
This almost certainly will not work. It has not been touched in quite some time.
A friend who writes Rust code said he would port the library, however I havent bugged him in a while about it (madk if youre reading this, this is you)
I go through phases of wanting to learn other languages for the purposes of writing libkarai in that language. This seems to quickly reach a barrier though, in that I have no idea which languages would be the most useful to write a library in, and also, none of the languages I want to learn are very popular at all. Some candidates are/were Crystal, V lang, Nim, LISP.
What is next?
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.
What does this mean?
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…
Some ideas for now…
As Karai is starting to reach a stable state, here are some new things that will be occupying my nights & weekends:
Some recent changes
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.
How does Subgraphs 2.0 fight spam?
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.
Give it a shot
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.
Karai Explorer - https://karai.io/explore
Icarus (Unstable) - http://167.71.104.172:4200/api/v1/stats
Daedalus (Stable) - http://46.101.200.220:4200/api/v1/stats
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.