This paper describes ideas for avoiding the high cost of fetching entire histories in a fork-consistent system. It also describes a technique to reduce the re-keying cost of removing a user from an ACL.
Why does the Frientegrity design take equivocation so seriously?
How does Frientegrity enforce fork consistency?
Is there any down-side to the fact that Frientegrity by default treats each object independently (end of Section 2.2)? What would an attack exploiting this look like?
If you run a SUNDR or SPORC system for a long time, the chain of operations will grow long and it will take clients (particularly new clients) a long time to fetch all the operations from the server. Suppose you modified SUNDR or SPORC to only fetch the most recent few operations. What attacks would then be possible?
Why is the tree (Figure 2) helpful in the design? How do clients use the tree to check for incorrect data from the server? Why does it work even though clients don't fetch all of the operations? Why does the tree make it hard for the server to give clients incorrect information?
Why isn't the tree sufficient? Why is the f mechanism needed as well?
Frientegrity requires that no more than f users with access to an object are malicious. Is that a reasonable requirement for social network applications? Is it reasonable for more general decentralized applications?
What value of f should a client use? Does the f+1 mechanism make sense if one doesn't know the other clients?
Why does it make sense for clients to read an object without fetching the object's complete operation history? Why is it safe?
Would the f mechanism be useful for SUNDR? SPORC? Bitcoin?
If two clients make concurrent updates (submit new operations at the same time, with the same previous operation), what happens? How do subsequent readers verify correctness in the face of an operation with two successors? See footnote 3 in Section 4.1.2.
In step 4 in Section 4.1.2, how does Alice know what op0 value to expect?
At the end of 4.1.2, what exactly has Alice established?
How does Section 4.2's entanglement allow a client to realize a server is doing something bad?
Suppose Alice has recently been deleted from the ACL for Bob's wall. Alice (conspiring with a malicious server) performs a writeObject() on Bob's wall, pointing to the old ACL (that still gives Alice permission). At what point would a reading client realize that something was wrong?
How does Frientegrity manage to revoke permissions without signing a new key with every remaining user's public key?