For now, assumption that we only put transactions into CB's will simplify things, but eventually we should have more generic types. Type requirements on DB lookups for hashes and endpoints simplify a lot of issues, but we still need more generic typing for collections of CBs to Nth order.
For this, we should re-introduce Bundle as primary data type to represent collections of CBs of CBs of CBs... etc to Nth order. There should be associated metadata similar to definition of a tensor (but this tensor is reflective of graph / edge data, hence the name bundle.)
Ideal starting point is to define a 'depth' or rank parameter. Given that mixing different ranks is ideal. An easy starting point is to look for the maximum number of nestings. I.e. take the 'maxDepthRank' of an arbitrary bundle. The actual rank should be fractional for mixed types. This should influence facilitator selection via reputation so that only higher nodes form higher depth / higher ranked bundles.
For now, assumption that we only put transactions into CB's will simplify things, but eventually we should have more generic types. Type requirements on DB lookups for hashes and endpoints simplify a lot of issues, but we still need more generic typing for collections of CBs to Nth order.
For this, we should re-introduce Bundle as primary data type to represent collections of CBs of CBs of CBs... etc to Nth order. There should be associated metadata similar to definition of a tensor (but this tensor is reflective of graph / edge data, hence the name bundle.)
Ideal starting point is to define a 'depth' or rank parameter. Given that mixing different ranks is ideal. An easy starting point is to look for the maximum number of nestings. I.e. take the 'maxDepthRank' of an arbitrary bundle. The actual rank should be fractional for mixed types. This should influence facilitator selection via reputation so that only higher nodes form higher depth / higher ranked bundles.