Jump to content
Vokez

Ripple Network forked to create SystemD

Recommended Posts

The Fork

We are very proud to announce that we have successfully forked the main Ripple Network in preparation for providing functionality for our security token platform called "The State". More information about The State is available at: https://vokez.io/platform.html 

This is a first hard fork of the Ripple Network and it is called "SystemD". The fork was performed around 0:05 GMT on January 11th, 2019, around ledger number 44317418.

Just as with hard forks of blockchain based currencies, any one who possessed "XRP" on the main Ripple Network at the time of the fork now possesses "SyD" on the new SystemD Network.


The Parallell Network

SystemD is the first parallel network. https://vokez.io/systemd.html

Being a parallel network means that all existing wallets, APIs, libraries, and other applications that work on the Ripple Network will also work on the SystemD Network.

The only configuration change that is necessary is simply replacing "ripple.com" with "vokez.io". For example, many wallets use the servers "s-east.ripple.com" and "s-west.ripple.com". To use the same wallet on the SystemD Network, you would simply change the servers to "s-east.vokez.io" and "s-west.vokez.io".


Our Goals

The way that the current Ripple Network is structured today, you need to make a serious investment in servers and network resources if you want to participate on the network. This creates a high barrier of entry for anyone who might consider participating on the Ripple Network.

One of our goals is to lower the barrier of entry of Ripple financial technology. There are enhancements that we will be implementing that will make it easier for the common person with common hardware to participate on the SystemD Network. 

For example we will be storing historical transaction data in a public distributed hash table. Then no one will need to store the whole ledger history. It will be collectively stored by all participants on the SystemD Network. Each person will only need to hold a small portion.

We want to exploit the massive potential of Ripple technology in a ways that have direct, positive effects on everyday people. 

One example of this is using SystemD to provide transaction processing for The State. The State is a security token platform that will empower companies, projects, and organizations with the ability to legally raise funds in accordance with local and international regulations. Transactions and other functions requiring consensus will be part of the sphere or functionality (SoF) that SystemD will be providing to The State. Read more: https://vokez.io/systemd.html#spheres-of-functionality

Another goal of ours is to implement a new currency distribution program. The first step of the SystemD currency distribution program is to nullify all of the largest wallets. Another aspect of this program is to give all registered members the opportunity to receive a daily stipend of 120 SyD


The Network

Our two main xts-rippled servers are:

- s-east.vokez.io:443
- s-west.vokez.io:443

Our three main validators are:

- val-east.vokez.io:51235
- val-west.vokez.io:51235
- val-r.vokez.io:51235


Run an xts-rippled server:

Github: https://github.com/VokezOfficial/xts-rippled

Docker: https://hub.docker.com/Vokez

docker run -d --restart=always -p 51235:51235 \ 
-p 5001:5001 -p 8080:8080 vokez/xts-rippled:latest

 

 

Social

Twitter: https://twitter.com/VokezOfficial

Share this post


Link to post
Share on other sites
9 hours ago, Vokez said:

For example we will be storing historical transaction data in a public distributed hash table. Then no one will need to store the whole ledger history. It will be collectively stored by all participants on the SystemD Network. Each person will only need to hold a small portion.

Awesome idea, where's the code for that?

It might make sense to integrate your functionality in rippled upstream and ask for more generalized support for competing chains (e.g. similar to how rippled by default has configs for testnet and mainnet). Similar to how clients like https://github.com/paritytech/parity-ethereum work.

Maintaining a fork of a large code base is hard, especially if you are currently just changing configuration files.

Share this post


Link to post
Share on other sites

 

13 hours ago, Pablo said:

 On first glance, it makes very little sense to create a fork of XRP

Could you give a reason or two why it would make little sense?

Share this post


Link to post
Share on other sites
17 hours ago, Flintstone said:

@Sukrim Is what you have quoted the same as https://developers.ripple.com/history-sharding.html ?

No.

History sharding is similar, but storing history (maybe optionally or in addition to sharding) in a DHT could have its own benefits and downsides. If only these "SystemD-rippled" nodes have this enabled, it would mean that they need to store a few TB of data on a few nodes, probably redundantly depending on their churn estimations. If they manage to get it onto all ~1000 rippled nodes, then there's still quite a lot of local storage used for the DHT data, but it would start approaching manageable levels.

Share this post


Link to post
Share on other sites
On 1/11/2019 at 3:36 AM, Vokez said:

For example we will be storing historical transaction data in a public distributed hash table. Then no one will need to store the whole ledger history. It will be collectively stored by all participants on the SystemD Network. Each person will only need to hold a small portion.

Nobody needs to store the historical ledger anyway, so in SystemD, the costs to run a node will be higher than running the real thing. For financial institutions, storing a few terabytes is not an issue at all.

The whole idea is very bitcoinish, where the current state of the ledger is defined by the entire history, yet in XRP the entire state is included in each block, and therefore requires a different mindset. Full history is cool, just a few copies is fine, but no requirement for the network to function. Codius would be the perfect solution to encapsulate a history node in a self-sustaining container, where people that want to access it pay for the operational costs with micropayments.

Therefore, since this fork does not solve a real-world problem, and actually creates one, either these folks have a poor understanding of the thing they forked, or they just want to enable a headline that “XRP ledger has forked” to create some FUD, and are not really interested in anything other than that.

And by the way: the title of this article is plain wrong and very misleading. The Ripple Network has not forked. Please edit, or @karlos, step in.

Edited by lucky

Share this post


Link to post
Share on other sites
35 minutes ago, lucky said:

Nobody needs to store the historical ledger anyway

I disagree. Keeping history will allow verifying that the validators are not misbehaving.

There was a tweet thread on this subject where Nik also joined in. Not sure where best to start that thread, but this is one of those tweets: 

Key in this is that you need a previous ledger (read - history) to be able to calculate the next ledger

Edit:

But besides that, I'm not sure the reason why they started the fork. Imo you should fork only if you disagree with the current status of a chain and can not come to consensus about the current way things are going. That would mean that they would have discussed their improvement points with Ripple and the community, and could not come to consensus, but I doubt that has happened

Edited by jn_r

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×