I've been thinking about this some more. The post above discusses my desire to say something specific in the whitepaper on the maximum ISP latency acceptable for running a Lisk mainchain node. (I am worried we are going to have a lot of disappointed Active Delegates when they realize they can't run a Lisk mainchain node from home on their spare PC and they actually have to rent a server at Vultr for $5 per month). I also ask for confirmation that sidechains can run at slower block times that the mainchain, and if that alone would allow the use of slower, high-latency ISPs.
These are important and hard questions that nobody really knows the answers for yet. One of my first goals when Lisk goes live with 0.5.5 is to set up some cheap sidechain nodes and run some timing experiments to get some answers. I want to give my future sports dapp customers great service!
We will have to do this as a community. I will try it from the office and from home. Then take the latencies to different IPs and post them. If we all do this, we should find a minimum.
Testing latencies as a community by stumbling around in an uncontrolled worldwide environment is very inefficient. I fear such efforts will not give us the answers we need.
Once the Lisk mainchain is running, I would strongly recommend setting up a closed cluster of 16 Pi2s connected by Ethernet, all running the guestbook dapp among themselves as a Lisk sidechain. Sixteen Pi2s is the maximum number of sidechain support nodes allowed by 0.5.5 if I remember the Crypti conversations correctly. You could throw this whole cluster together for around $1000, maybe even run it as a Lisk-sponsored thesis project in the Aachen university environment.
Once this test cluster is up and running, the next step is to start putting known test latency delays between the nodes, slowly increasing these delays until the sidechain delegate network finally fails. Lots of valuable scenarios could be examined and documented in a whitepaper. There's lots of software that is used for network testing of this sort, and even people who specialize in doing such test setups. Maybe you could hire them as a consultant if there is no interest in doing it as an Aachen area engineering project. See as an introduction:
http://bencane.com/2012/07/16/tc-adding-simulated-network-latency-to-your-linux-server/http://www.linuxfoundation.org/collaborate/workgroups/networking/netemhttp://wanem.sourceforge.net/http://www.trafficsqueezer.org/Max, controlled testing like I am proposing here would provide vital information required to convince and sell major businesses into running enterprise dapps on Lisk side chains. This kind of Pi2 cluster research would be relatively cheap. You have the financial resources now to easily do such testing. These tests would show Lisk is a serious player willing to prove our performance claims with hard facts and proven numbers. Having a Lisk sidechain engineering test bed like this would be an invaluable resource. I urge you to delegate the task to someone to set such a testbed up as soon as possible, so testing can begin as soon as the Lisk mainchain starts.
I love how you think Mal. Scientific.
You make a very valid point in addressing latency and ways to figure out how to maximize the network. It could very well be the start of peer reviewed research for Lisk.
In my opinion though, there are some potential issues with the proposal that will need to be addressed to move forward with this:
- Guidance - Right now Olivier and Max have their full attention on Lisk, they would have to hire someone to guide the project and report findings.
- Time Sink - IF Lisk decides to test this themselves, it would inevitably distract them from Lisk core development, causing a rift in time management.
- Funding - They would need to address how much they are willing to spend on the project, and if it is worth it.
With this in mind, I can see how testing it in different IP's might be an issue, as there would be no control group. But, we might as well try (it's free, doesn't need guidance and would not distract core development) since the community is one hell of a resource.
Oh, by the way, this post is not meant to start a discussion whether it can or cannot be done. I highly believe it CAN be done, once the potential issues (and maybe others I've missed) have been addressed.