PoW#01: Releasing ditCLI v0.2 and other Updates
Progress Report on the ditcraft technology stack
Recently we released an extensive update to the ditCraft technology stack. This update included so many different things in a lot of components, that a lot of them could have been missed easily. This is why we came up with our own version of “Proof-of-Work” in the form of this article.
We released an update to the ditCLI, namely version 0.2, containing many improvements on the user experience and more detailed information on the individual results of votes. In addition to this we launched our own version of a KYC — or as we call it Know-Your-Coder — where users just send a simple tweet to our Twitter account in order to get verified.
On the smartcontract side we prepared everything to be easily upgradeable in the future and deployed all the contracts to the xDai network. In addition to the quick 5 second blocktimes it is also a lot cheaper to interact with our smartcontracts there, reducing the estimated yearly cost for a developer using dit from >$100 USD to just some cents.
We are also working on a new webUI, which will allow anyone to easily interact with our ecosystem without needing to enter the command line. Furthermore, we now started to migrate the git integration of our ditCLI to the native git library to move from a proof-of-concept to something that is ready to be used in live development systems.
With the most prominent part of the ditCraft family being the ditCLI, a lot of time has been spent on improvements here. Special emphasis was put on the user experience, since we believe that a smooth UX is the key to establish the ditCLI as something that people actually like to use every day. This includes simple warnings when a user is about to delete an existing Ethereum key-pair during a setup of the CLI, but also an improved process of updating the CLIs’ config after an update of the CLI itself.
Also, we increased the amount of information a user receives after a vote has been finalized. Now you will not only see whether a proposed commit has been accepted or not, but also how many validators have participated and the percentage of their votes. In addition to this, users may now easily switch between the demo and the live mode of the CLI. While the demo mode is essentially the same as the live mode, the staked currency and knowledge tokens (KNW) are just for testing purposes. Users may play around with the CLI and test its features there before moving to the live mode, where real xDai is being staked and real KNW are minted (and potentially burnt).
KYC — or Know-Your-Coder
One of the biggest challenges and threats when designing the protocol behind ditCraft are Sybil attacks. With public and permission-less blockchains like Ethereum, it’s incredibly easy to create thousands of accounts on the matter of a second and participate in public protocols like the one we implemented.
To mitigate this, we came up with the idea of a KYC, which in our case stands for Know-Your-Coder. The idea is quite simple: we only allow users to use our ditCLI and smartcontracts after they have proven to be a legitimate person instead of a Sybil or fake bot account. Since Twitter is incredibly famous in the Ethereum community, we are starting of with a Twitter-based KYC. To do this, we wrote a Twitter bot, that is able to automatically handle these KYC requests.
So how does it work?
The user downloads the ditCLI and is being asked to perform the KYC by tweeting the CLIs’ generated Ethereum address like this:
Our Twitter bot then performs a KYC based on the users profile by taking the amount of followers, tweets and the accounts’ age into account. After the user passed this hurdle, the bot automatically enables the user to interact with our smartcontracts by adding their address to the list of authorized addresses.
Future Smartcontract Upgrades
While we didn’t change anything about the basic idea and concept of the smartcontracts and their logic, we did some improvements. The most important one being that we restructured them in order to be upgradeable. The idea behind our upgrade concept is actually quite simple: each contract has two additional address variables: lastContract and nextContract. Upon the first deployment (v1), these two variables are empty. If we now update the smartcontract or add new features to it, we deploy the new smartcontract to the network (v2) — but this time, the lastContract variable will be set to the address of the old contract (v1). This way, everyone who interacts with the new contract (v2) will know that there exists an older version of the contract, where previous information about votes can be obtained. Upon deployment of the new contract (v2), the variable nextContract in the old contract (v1) will be set to the one of the new contract (v2). This way, we can limit interaction (namely the initiation of new votes) with the old contract and CLIs who still try to reach the old contract may obtain the new address through this variable.
Since publicly accessible functions in a smartcontract need to be secured in some way to prevent abuse, we introduced something called the ditManager. Only the ditManager is allowed to perform the upgrade of a smartcontract through the upgradeContract(_addressOfNewContract) function. While in the beginning the ditManager will be an address held be the ditCraft team, it is close to our heart to hand this control over to a smartcontract-based DAO such that the ditCraft community is able to vote on these upgrades to further decentralize the whole process.
Deployment on xDai (PoA) Network
With our recent update, we also deployed our smartcontracts to the xDai network, an Ethereum sidechain run by POA Network that uses xDai as its native token (instead of ETH). While we are big advocates of Ethereum and its mainchain, we believe that a faster blocktime and a stable gas price is something that dit immensely benefits from. We want our users to use the ditCLI on a regular basis, not just every couple of days to interact with an important vote. Nearly every commit to the master branch of a repository can be turned into a vote — but only if it’s quick and affordable. Even if the gas price stays as low as it is today on the Ethereum mainnet, our potential users would face a yearly cost of $70 to >$250 USD, while also waiting at least 15 to 60 seconds for a transaction to go through. With the xDai network, we are able to cut that yearly estimated cost down to not even $0.40 USD, while transaction are confirmed in 5 seconds (the blocktime of xDai). To give you more of a concrete idea on how much cheaper it is, lets look at the following examples:
- Cost of a proposal on Ethereum Mainnet: $0.10 to $0.50 USD
- Cost of a proposal on xDai: $0.0006 USD
- Cost of a vote on Ethereum Mainnet: $0.05 to $0.25 USD
- Cost of a vote on xDai: $0.0003 USD
An additional benefit is the fact that xDai, being a representation of MakerDAOs DAI, is a stable coin that is pegged to the US dollar. One xDai is always worth one US dollar, instead of fluctuating like Ether. So even if you initiate a long vote through an important commit to the code, the amount that you staked in the beginning will still have the same value on the last day of the vote. This wouldn’t be possible with ETH.
ditCraft webUI (ditExplorer)
As you might have seen during our latest sneak peek on Twitter, we are now working on a webUI. As this is still in early stage, we cannot really tell much about it, rather than just showing little screenshot. But stay tuned, the first version of the webUI might come sooner, rather than later.
While we are quite happy with the current version of the ditCLI, it lacks the fine granularity of git commands that the native git command-line-client offers. This is what we are currently working on, namely integrating the native git library libgit2 into the CLI in the form of git2go, since the ditCLI is written in Go.
In parallel, we are working in the first version of the webUI mentioned above. A first version where users are able to see their KNW balance in a web browser and search through the different proposals and votes will be released next.