I'm not really familiar with these, but are these consensus mechanisms actually designed to prevent cheating / deal with dishonest participants? And when you talk about "partition", do you mean that r...
byzantine fault tolerance is one of the ways you get a partition resistant system. bitcoin vs proof of stake systems is the bitcoin favors has stronger availability but weaker consistency (6 blocks probabalistic finality) the pBFT based proof of stake systems have weaker availability (stop failure) but higher consistency (fast finality).
when there is no utxo or transaction graph in the data, availability and consistency is the better pattern. for your inkan use case, bitcoin style consensus is a better fit. but without needing to be anchored except in the small chains of user delegations, partition resistance is less important. which means you can do it using an eventually consistent protocol, the bestmexample of that is amazon, facebook, they focus on availability and geographically shard. partition resistance is very weak. pnyxdb is an example of this pattern generalized. i would implement it by a distributed dispersed relay type that seeks fast replication using lamport clocks and bolsters availability by broadcasting and subscribing to the delegation events in open relays.
nostr's self standing events, which areappend only, fits very well to simply ensuring availability, the cryptography ensures consistency without consensus, by using broadcast.
there really is no need for a consensus for delegations. only aggressive propagation. a specialised relay that focuses on your data type achieves this. the security would come from subscriptions ensuring the relays have high uptime and fast cross propagation.
i think a small subscription would work better than paying per record because anyone who uses it needs those chains.
when there is no utxo or transaction graph in the data, availability and consistency is the better pattern. for your inkan use case, bitcoin style consensus is a better fit. but without needing to be anchored except in the small chains of user delegations, partition resistance is less important. which means you can do it using an eventually consistent protocol, the bestmexample of that is amazon, facebook, they focus on availability and geographically shard. partition resistance is very weak. pnyxdb is an example of this pattern generalized. i would implement it by a distributed dispersed relay type that seeks fast replication using lamport clocks and bolsters availability by broadcasting and subscribing to the delegation events in open relays.
nostr's self standing events, which areappend only, fits very well to simply ensuring availability, the cryptography ensures consistency without consensus, by using broadcast.
there really is no need for a consensus for delegations. only aggressive propagation. a specialised relay that focuses on your data type achieves this. the security would come from subscriptions ensuring the relays have high uptime and fast cross propagation.
i think a small subscription would work better than paying per record because anyone who uses it needs those chains.
1