iotaledger / bee-rfcs Goto Github PK

These are features of Bee important for qubic assemblies
Note, that this is draft, however it can impact modular structure of Bee.

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

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

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

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

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

@iotaledger/bee-devs With some conversation on #4, we should better start figuring out the basic layout of type Trits and open its RFC at the meantime. Here's proposal of @zesterer in trit's manner:

pub trait RawTrits {
    fn with_capacity(n: usize) -> Self;
    fn double_in_place(&mut self) -> bool;
    fn reserve(&mut self, used: usize, needed: usize);
    ...
}

pub struct RawTritPerByte {
    trits: ...,
} 

impl RawTrits for RawTritPerByte {

}

pub struct Trits<T: RawTrits>{
    raw: T,
}

impl<T: RawTrits> Trits<T> {
    pub fn new() -> Self {
        ...
    }
    
    pub fn with_capacity(n: usize) -> Self {
        ...
    }
    
    pub fn push(&mut self, x: Trits) {
        ...
    }
    
    pub fn pop(&mut self) -> Option<Trits> {
        ...
    }
}

So it can have default type something like struct Trits<T: RawTrits = RawTritPerByte> in this way. We still have a couple of questions remain and I would like to see if some one wish to take it and start a RFC with this.

• What trits encoding are we going to start first?
• Or should we implement both at once?
• How to do hashing with different encoding
• What method should we provide at least to defin in trait RawTrits?

1. Configuration format file should be aligned with one format. HOCON, e.g., if adopted in Bee, then it should be also adopted in Chronicle, to make the configuration files consistent and easy to maintain. In addition, adaptive runtime configuration should be implemented, in this way, e.g., a crashed node/chronicle can read an updated configuration file and reboot itself (or be rebooted) properly.

2. Because we never know what kinds of data the users need for their applications/analysis, one of the flexible approaches for data collection is to use Bee gossip and Bee solidifier to subscribe and prune transactions. A dedicated pruner should be designed in the Chronicle, so users can choose which kinds of data to remove.

3. If the user wants to collect confirmed transactions only, then Bee EEE should be adopted, so confirmed transactions can be subscribed directly by the Chronicle, without post processing.

4. In the Chronicle’s point of view, it is necessary to make sure that the subscribed Bee node(s) can see the whole tangle (except for the old transactions removed after snapshots), and every transaction visible to the node can be sent to the Chronicle by Bee data dissemination protocols (EEE or gossip), so the Chronicle will not lose any (confirmed) transaction. Otherwise, which kinds of transactions cannot be sent to the Chronicle should be known beforehand, and the user can know these specific transactions cannot be collected.