You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 7, 2023. It is now read-only.
These are features of Bee important for qubic assemblies
Note, that this is draft, however it can impact modular structure of Bee.
possibility to use gossip as transport for multiparty communications within closed broadcast group of nodes, not only neighbors. The use case would be some nodes with IDs listed in a transaction on the tangle want to establish broadcast group with all messages exchanged between members only.
I also think it must be evaluated in the context of sharding.
meta-transaction layout, multiple types of transactions. For example the assembly transaction will need "assembly ID" and "epoch index" fields. "Normal" transactions don't need it
type-specific transaction (bundle) validation rules. For example assembly epoch transaction (a bundle, actually) has specific validation rules for signatures, structure etc, even being zero value. Also, epoch bundle may contain value transactions for distribution of rewards among nodes, so coin ledger state must be validated too.
So, validation rules may be much more complicated than just checking consistency of coin ledger state. An invalid epoch shouldn't be confirmed by the base protocol.
Transaction-specific rules of detection of conflicting transactions (bundles). For example, two valid epoch transactions with equal assembly IDs and equal epoch indices are conflicting, we need strictly chain of epochs, no forks.
The two can't be included into the same ledger state, just like double spends.
Tentatively: updates of the assembly state may be validated by repeating calculation of the qubic against the input. Wrong results means the state increment shall be rejected by the network. This way assembly state may be validated even by nodes outside the assembly itself, for example by expanding nodes running the assembly.
Theoretically, the above can also be implemented in the upper layer of the protocol, however that would be unwise, because most of complicated stuff can easily be done by the base protocol, just with plugged-in validation and conflict detection rules.
The text was updated successfully, but these errors were encountered:
On the gossip
Each gossip message can have optional list of nodes, optional maximum broadcast distance and the originating node. No list means global broadcast. 0 maximum broadcast distance would mean no maximum distance (whole network).
The distance may be distance in hops (the counter in the packet) or it may be some distance, calculated by receiver node to originator node, a "sharding distance".
Receiving node would forward message to its neighbors if maximum distance is not reached yet.
For example broadcasting a message to a group of nodes with distance 1 will result exactly in closed broadcasting group of nodes. With distance 2 it is the group and its neighbors.
These are features of Bee important for qubic assemblies
Note, that this is draft, however it can impact modular structure of Bee.
possibility to use gossip as transport for multiparty communications within closed broadcast group of nodes, not only neighbors. The use case would be some nodes with IDs listed in a transaction on the tangle want to establish broadcast group with all messages exchanged between members only.
I also think it must be evaluated in the context of sharding.
meta-transaction layout, multiple types of transactions. For example the assembly transaction will need "assembly ID" and "epoch index" fields. "Normal" transactions don't need it
type-specific transaction (bundle) validation rules. For example assembly epoch transaction (a bundle, actually) has specific validation rules for signatures, structure etc, even being zero value. Also, epoch bundle may contain value transactions for distribution of rewards among nodes, so coin ledger state must be validated too.
So, validation rules may be much more complicated than just checking consistency of coin ledger state. An invalid epoch shouldn't be confirmed by the base protocol.
Transaction-specific rules of detection of conflicting transactions (bundles). For example, two valid epoch transactions with equal assembly IDs and equal epoch indices are conflicting, we need strictly chain of epochs, no forks.
The two can't be included into the same ledger state, just like double spends.
Tentatively: updates of the assembly state may be validated by repeating calculation of the qubic against the input. Wrong results means the state increment shall be rejected by the network. This way assembly state may be validated even by nodes outside the assembly itself, for example by expanding nodes running the assembly.
Theoretically, the above can also be implemented in the upper layer of the protocol, however that would be unwise, because most of complicated stuff can easily be done by the base protocol, just with plugged-in validation and conflict detection rules.
The text was updated successfully, but these errors were encountered: