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 scattered 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. These tests would show Lisk is a serious player on par with Ethereum, willing to prove our performance claims with hard facts and proven numbers on bare metal hardware. This kind of Pi2 cluster research would be relatively cheap. You have the financial resources now to easily do such testing. Having a Lisk sidechain engineering test bed like this would be an invaluable resource. The photos alone of such a testbed for use in Lisk public relations would be a justifiable advertising expense if nothing else. I urge you to delegate this task to some local engineering student whose progress you can easily monitor. Have them set up such a testbed as soon as possible, so testing can begin as soon as the Lisk mainchain starts.
Ha. Here's somebody coming at you with a crazy idea on how to spend some of that new Lisk development money you now control. Use me as a test case on learning how to handle such fools!