One hash to describe the entire state of the world.
The mechanism by which children update their parents is required.
This is needed to enable block queries to have a consistent answer, since "latest" is subjective, so all queries are relative to the latest root.
Possibly each chain also gets updated with a root hash, so any queries can walk straight back to root.
Start of each block run should be to update the root hash if it has changed, allowing chains to only change the root when it is time to block.
If children update their parents when their state or meta changes, then those parents can in turn update their parents, up until the root is altered as a result. Only then can the change said to be propagated, as this latest change will show up in queries from other chains. The latest root is always included at the start of each execution, and is a reason why a block producer can reject a proposal, if the root is too stale.
A chain may include a root hash which does not include its latest block yet, as the propagations may not have occurred yet. Parents will not delay updates, as this ensures strong consistency of the application tree. A change is only fully committed once the root acknowledges it, as it makes that chain available for queries from anywhere in the application tree. Chains will always attempt to use relative paths when using queries, as these will be more up to date than the root.
The root channel is special in that it does not necessarily bestow any rights upon the recipient, and it is not reflected in the root chain itself. This is a type of one way broadcast channel.
The changes continue to propogate up from child to parent until the child rests with a new block whose only difference is a new root chain hash added to it. This stops endless updates, while ensuring that a block is formed in the child that assures root inclusion. However this root inclusion block can be kept as pending if we rely upon the block producers always using or requiring the latest root to be included in every block they produce. The child may have set something to trigger on root hash update
Care should be taken with triggers based on root hash updates as endless loops may be triggered. We can possible solve for these if they are observed, but we might kill some false positives too.
One hash to describe the entire state of the world. The mechanism by which children update their parents is required. This is needed to enable block queries to have a consistent answer, since "latest" is subjective, so all queries are relative to the latest root. Possibly each chain also gets updated with a root hash, so any queries can walk straight back to root. Start of each block run should be to update the root hash if it has changed, allowing chains to only change the root when it is time to block.
If children update their parents when their state or meta changes, then those parents can in turn update their parents, up until the root is altered as a result. Only then can the change said to be propagated, as this latest change will show up in queries from other chains. The latest root is always included at the start of each execution, and is a reason why a block producer can reject a proposal, if the root is too stale.
A chain may include a root hash which does not include its latest block yet, as the propagations may not have occurred yet. Parents will not delay updates, as this ensures strong consistency of the application tree. A change is only fully committed once the root acknowledges it, as it makes that chain available for queries from anywhere in the application tree. Chains will always attempt to use relative paths when using queries, as these will be more up to date than the root.
The root channel is special in that it does not necessarily bestow any rights upon the recipient, and it is not reflected in the root chain itself. This is a type of one way broadcast channel.
The changes continue to propogate up from child to parent until the child rests with a new block whose only difference is a new root chain hash added to it. This stops endless updates, while ensuring that a block is formed in the child that assures root inclusion. However this root inclusion block can be kept as pending if we rely upon the block producers always using or requiring the latest root to be included in every block they produce. The child may have set something to trigger on root hash update
Care should be taken with triggers based on root hash updates as endless loops may be triggered. We can possible solve for these if they are observed, but we might kill some false positives too.