...
If they have particular contracts that they are interested in, they run a node that targets specific contracts or wallet addresses, and the node can keep track of the events that occur in the transaction stream that affect the wallet address, and log those separately as desired. Which enables them to specifically target their dApps traffic. Generate a separate log that is a subset of the traffic.
Joining and Leaving
...
Shards:
When a node joins a namespacevalidator bonds on to a shard, it has to ask out of protocol who the current validators are, and then ask for some blocks to determine the current root state hash, ask for the current state itself and then verify that the state they received matches the current root state hash. The node will also need to download the blockchain for the namespace shard itself. The download of the blockchain itself can happen as a background process, it should not be necessary for the entire blockchain to be downloaded prior to the node's ability to contribute to validating transactions. So long as the node has the current state, it should be able to validate transactions and propose blocks.
When a node leaves a namespaceshard, the local blockchain data should persist on the node unless the node operator explicitly chooses to remove the data. The node operator should be able to observe a list of namespaces and associated blockchain data within the web interface. This interface should also provide a mechanism to remove the data, or rejoin the namespace. If a node re-joins a namespaceshard, the process to re join a namespace shard is the same as a new node joining the namespaceshard, with the exception that the entire blockchain for the namespace shard need not be downloaded, only the missing data should be downloaded. The protocol to join a namespace should identify the last downloaded block (outside of the blocks needed to set the state) and only send the blocks the node is missing.
- Medha Parlikar (Unlicensed): Determine/specify what happens if a node has old or incompatible data & it attempts to join a shard after unbonding.
With the introduction of garbage collection of blockchain data & Rent post Mercury, a node need not download the entire blockchain (unless they are joining a namespace shard that explicitly serves this purpose) - for the Mercury time frame, the blockchain will not be that large, so downloading the entire blockchain keeps the data across the nodes in the namespace consistent. Similarly, once Rent is implemented, the validators in the namespace can decide how much of the blockchain to persist, and a new node will have to adhere to those rules, or propose a change to the GC rule for the namespace.During the time when a node is determining which namespace to join, it should temporarily connect to the 'root' namespace, where the information of the entire network exists? This way the node can be offered a set of shards to join? This root node should have access to all the shard properties.