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
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.
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.