Considerations for using sidechain elements in sharding:
https://medium.com/chainsafe-systems/ethereum-2-0-a-complete-guide-scaling-ethereum-part-two-sharding-902370ac3beIn fact, the sidechains are very reminiscent of the logic of interactions inside a skyscraper where a given number of couriers move.
Skyscraper with unlimited size and number of floors, without problems from wind and gravity.
There is a bottleneck problem in the form of elevators for interactions between floors, but there are solutions.
And I don’t remember that between floors the customs, border guards or parliament had a tendency to regulate the movement
In this example, it’s important not to mix flies with cutlets. There are addressing principles.
Floor, office number, name of the addressee.
For movement between floors, the office number, addressee and contents of the package are not important at all, we are only interested in the number of "couriers" differentiated between two separate floors and the task is to optimize only this "movement process", the rest of the data is important only within the floors locally and these values not important
The “balance of couriers” simply changes between two separate floor addresses.
What are our solutions?
Elevator express when a package of “couriers” is dynamically formed from the general queue of movement
There, in turn, priorities for the formation of packets on the "traffic" or "sending time limits"
Addressing the "elevator" when the "packets" travel between floors on elevators A, B, C, D, E, F and so on ...
Differentiation of directions for distributed systems does not matter much, but do not forget about it
Do you think this logic cannot be used in the sidechain system?
But it’s also easy to cascade