GOSH 2.0 Release

What's new in our latest release

GOSH 2.0 has been around for a while. If we’re being pedantic about it, the newest GOSH system architecture release is actually several iterations after 2.0; but we’re not pedants (though we feel compelled to inform you this is version 2.0.8), we are humble programmers in search of some food and some lodging. So let us go down the dark road of confused numerical titles without fear, and know once and for all that we have something in common with Apple.

We feel it’s time to finally discuss, herein, what GOSH 2.0 even is, what has changed (quite a bit), how it affects users, and what to expect next.

Think of this as a milestone roadmap post, because GOSH 2.0 is a milestone of blockchain design bringing us ever closer to a fully realized git on-chain that can compete with any centralized solution in use today. And then send any centralized solution into long, tearful, isolated exile tomorrow. Maybe we’ll even get a protest album out of it, who knows.

From the very beginning, we at GOSH chose to follow an iteration of agile development, keeping in mind the philosophy of “release fast, release often.”

GOSH is a distributed programming paradigm software. It avoids hashmaps as much as possible because they are centralized and thus not very scalable in decentralized systems by nature; instead we chose to distribute them to the whole contract space, in line with the approach of GOSH’s content addressable blockchain design. But as with everything else, we choose to follow the principle of Entia non sunt multiplicanda praeter necessitatem (obviously).

In the first version of GOSH we did a little bit of that. We deployed every blob diff as a separate object, and a user would need to collect all objects to apply diff. While this offered us a great amount of flexibility, it also hampered scalability and was painfully slow. In order to fix it we had to change the GOSH blockchain Virtual Machine, adding a DIFF instruction set to it. Now DIFF can be applied as a smart contract instruction. Which looks something like:

Now, we have created an object called a “snapshot.” This is really just a last version of a file. Of course, we have commits as separate objects deployed by a user, so the question becomes: how do we actually store the history? The answer is the blockchain itself: the best log available (we have written about it many time

s before).

All messages passing from the user wallet to the commit contract and from the commit contract to the snapshot are stored in GOSH blocks. In order to get the git history, we just take past blocks and filter out messages from the commits that users are looking for, which go to the snapshot and reconstruct all changes to the file. It looks something like: 

BTW, ipfs is used for large binary objects only

The history is provable. This is because you can prove blocks belong to the blockchain, yet even more importantly, you can prove the time of every change made to every repository. This is hugely important for security.

We still have some work to do with Snapshots as they now are copied each time a new branch is created. That is something we are going to work on for the next release. 

Another important change from 1.0 is the new GitHelper. To develop it quickly, the first version was written in Node.js. This, of course, meant that it was slower than we need it to be. With 2.0, we rewrote it using Rust, we parallelized it, and are glad to announce that it’s lightning quick.

We also now have supported parallelization on the smart contract side. Say you want to push a new repository, and you have a large number of commits, well, if you’re using GOSH 2.0, instead of passing through a single user wallet, as before, many user wallet contracts are now spawned to support as many parallel messages as needed.

While we are still working overtime to further shorten the wait of pushing large repositories, on GOSH 2.0 you wait much less than before. With the time it takes now reduced by several orders of magnitude.

Expect future releases to improve this even more, seeing as now the main structural reasons for slow performance have been removed.

Protected branches are added. Instead of just one main branch requiring DAO voting for a merge, users can choose any branch to protect with DAO voting. This is extremely important for social engineering attack prevention.

And finally, in UI Improvements, we now have an identical interface in the Docker Extension as in the Web version.

IMPORTANT NOTES:

To work with version 2.0:

• Please make sure that you have the latest root contract addresses at the bottom of the screen when working with web interface or Docker Extension

• The new GitHelper won’t work with old repositories. So users need to download previous versions to access them. This will be automated later (see below)

Now let us tell you about what we are working on and you can expect in future releases.

1. The first thing on our list is sleep. We need to get some of that now. 

2. Just as we wake up we are going to finish up Support Contract Upgradability. Which is a fancy word for “versioning” really. On GOSH, contracts are optionally upgradable. But it is not always a good idea from a security standpoint. And security is the prime reason to use GOSH. So upgradability needs to be designed and implemented really carefully.

3. In parallel, the Pruvendo team will release an enhanced version of DAO contracts that will support DAO management capability. Today, when an organization is created it will automatically assign 100 tokens to each member for SMV voting purposes. Obviously we have very big plans for our DAO roadmap. We are going to talk about it in a separate post in more detail, so stay tuned.

4. Refactoring and Branch contract deduplication. Speed of work is our top priority so we will continue to enhance this part until we beat GitHub. Is it at all possible in a decentralized distributed system? Yes it is! But it will take some time — another post explaining the GOSH blockchain’s architecture is coming as well.

While we would like to insert the “Oh my Gosh” joke we’ve wanted to include in everything we’ve been writing, we’ll put that one off for another day. Instead, let's end this by calling upon you to try it out, and let us know what you think.

For future updates on all the exciting things we’re releasing, try subscribing.