We brought you news about Gitchain a while back. Created by a single Canadian developer, Yurii Rashkovskii, it is currently accumulating funds on Kickstarter. It long ago reached its goal, thanks in large part to a single anonymous donor. Gitchain hopes to make a secure decentralized network for developers to post their projects on without fear of censorship or financial issues bringing it down.
I talked to Rashkovskii via Skype, temporarily interrupting his trek through SE Asia. I found him to be a personable and approachable man who is very talented at explaining complex technical issues in a simple way.
But it is his take on Git technology and its combination with Bitcoin that really stands out.
Cointelegraph: You have stated that you don't want Gitchain to replace GitHub, but to work with and enhance it. Can you talk a little about the advantages Gitchain potentially brings to Git?
Yurii Rashkovskii: One of the ways I am seeing this project is that it is an attempt to push the envelope of how we use certain services and ask why are they centralized and if they can be decentralized and what kind of implications will that bring to the table. So, what do we gain and what do we lose as we try to move to a decentralized service, where today we use a centralized one.
If, theoretically speaking, Gitchain became a dominant platform for developers to push their code to; there is absolutely no reason for GitHub or BitBucket to not use it. Basically, they would solidify their platform by also being a participant [in Gitchain] and using the decentralized network.
What that means is Gitchain doesn't replace GitHub, it just provides a storage solution and name reservation service that is not at the mercy of a single company.
For an example, if GitHub were to go out of business, they wouldn't have to worry about giving projects back to their developers, they would remain on Gitchain.
CT: From reading materials about Gitchain, I have learned that all of the object data won't be stored on the blockchain but will be sparsely distributed across each node, can you go into a little more on what that means?
YR: So basically, the purpose of the blockchain is to establish a consensus, and not to necessarily distribute data. Basically, everything that happens on the Gitchain network, like registering a name or pushing your data to a repo, all those events are recorded on the blockchain. So everyone has a meta-history of the Gitchain network. The rest, the actual data of commits is stored in the DHT (distributed hash table network). Every object published is sent to a redundant number of nodes.
So the more objects you have in the system, the more spread out they are and the larger the network grows. The hash of each object, combined with the blockchain, will point to which set of nodes hold the data and each node will have roughly the same number of git objects stored on it.
Since the object is sent to enough nodes to be redundantly stored, if one or several nodes go down or fail in some way, the hash of your object can simply point you to the next one.
CT: I want to talk about how you create an incentive to provide storage. I have heard a lot of suggestions for proof-of-storage models. How do you plan to create an incentive for users to store other user's project, and also, how do you plan to keep people mining?
YR: Well, let me split this in a few different things: mining is one aspect, and is used to build consensus and doesn't really have much to do with storage. There are some good ideas out there on how to intertwine the two, but for now I won't get into that.
The other question that is really great is how do we provide an incentive for people to provide storage space and essentially bandwidth for people. So far, I have tried to split the project into two stages. I want to complete both stages before the launch but in the first stage I want to sort of skip the issue of making an incentive for space and just build something that works. At that point, there won't be any kind of economy built into it yet, but it does the functionality that it was built for.
The second step, where I have been putting a good fraction of my time, has been devoted to researching proof-of-storage, which is still a new concept. If you Google it, you'll find that most of the papers relating to it were written in the past seven, maybe ten years or so. Most of that has to do with getting data into the cloud, and not projects like Gitchain. It is more about making sure cloud providers are actually safely storing data.
Here, we have a potentially larger network that checks itself in a better way than depending on a single centralized provider and auditor. So, I am trying to combine the math behind those papers with the math behind decentralized networks like Bitcoin.
To be honest, there is still a lot of fairly complicated material to go through. Sometimes I feel like it is a little bit over my head, but I am trying to extract the most valuable ideas and see what can be done in this space.
I'm also trying to look at it from different perspectives. When it comes to name verification and registration, it is the same technology that Namecoin uses for its [web domain] registration, which already works well.
Basically, Gitchain goes back in time and determines the distance between a reservation transaction and the allocation transaction. If the distance is long enough, the software assumes the name allocation went through correctly.
So proof-of-storage may work in a similar way. So you won't be given a token, but the address that provided that storage, every other user in the network can verify that they did provide the storage using the blockchain. So this kind of transaction could reward that address, and we will all agree that the certain address will have a certain balance in it. Once we make a way for that balance can be transferred, [and] then it sort of monetizes the system.
The big question here is what is the best way to do proof-of-storage, and I suspect that will be a large part of this project. But like I said, I want to work on making the project work before I add any kind of economy. I think it will be much easier to find out once we let people play with the idea in a closed environment [beta].
CT: One thing I noticed looking at your project on Kicktraq, roughly $8,000 was donated on the second day, by far your biggest. Can you tell me a little bit about that? Was it a big donor, or just several small donors that happened to find you that day?
YR: Due to privacy laws and Kickstarter's agreements, I can't say much. But, what I can tell is that it was one backer who pledged a big chunk of money, but I can't really tell more.
I wish I could, and there will be, or likely will be some more information about this released to the public. But I'm not ready to do it yet, I can tell you the pattern but not much more than that.
CT: I was wondering why you choose Kickstarter over IndieGoGo or bringing the idea to Bitcointalk or something like that?
YR: Well, the reason I didn't want to bring this to the Bitcoin community too much is because the goal, or one of the goals of this project, is to expose ideas behind crypto, blockchain and related areas to a broader audience of developers. So, [it’s for] someone who has not really dabbled into the technology just yet. That was the motivation behind bringing it to Kickstarter. It is the most mainstream crowdfunding platform. One could argue IndieGoGo is also fairly mainstream, but Kickstarter has a kind of glossy image to itself.
I experimented with IndieGoGo but I didn't launch anything. Being Canadian, I wasn't able to work on Kickstarter easily at first, at least without a U.S. bank account. But, I found out that they have been working with Canadian banks recently and so I figured I would try it out.
There isn't a real good reason why I chose Kickstarter over IndieGoGo, other than I just chose the most mainstream platform, to try to reach the widest audience.
CT: When do you think Gitchain will be available in a Beta or even Alpha form? Is there any timetable?
YR: Obviously, it is a fairly complex project. So my plan is to have it ready for use in a test network, one of those test launches I alluded to before, I am expecting that to be around September.
The code I have right now isn't fully functional, it is only a prototype. It does certain functions and it does serve as a Git server. It is easy enough to build a working prototype, this one is two weeks old. But it will take a considerable amount of time to fix all the corner pieces and rewrite the sections needed to keep it from falling apart.
A big part of this summer for me will be spent trying to learn more about the code and how to improve it, while still continuing the discussions with the community about the incentives and proof-of-stake and other issues.But given the track record of this project so far, it does still seem possible to me to have a working version by September. One that is useable but still has some bugs, which is expected at this point.
I will also need to spend some time on the DHT library. The version I am using appears to have been abandoned by its developers but I may have to reach out to them to figure some things out.
I also want to bring along some smart people in the community to help me make decisions regarding Gitchain and what directions we want to take it in.
CT: Last thing - is there anything I didn't touch on that you would like to convey to our audience?
YR: The only thing that I can say, and I have been saying a lot in talks to people is: A big part of my personal motivation in this project is to promote and enable further experimentation in the space and make all those interesting ideas more attainable and spread across the broader population of engineers.
That is a big part of what I want to accomplish Gitchain.
We want to give a heartfelt thanks to Yurii for taking time out of his busy schedule to talk to us. You can find Gitchain on Kickstarter here.