Include security assumptions for Ambients

[nud3l]

Background

Ambients are intended to be used in decentralized systems. However, from the paper, it is not really clear to me what the underlying security assumptions are. For example, what if messages get re-ordered, delayed, etc. by a strategic and non-strategic adversary. It would be great to have that as part of the white paper!

As far as I understand, you can use a blockchain as the basis for Ambients (which would tolerate Byzantine behaviour up to certain thresholds) or Merkle-CRDTs as in OrbitDB. If you use OrbitDB, I think, you cannot tolerate Byzantine behaviour, but "only" liveness failures, if my understanding is correct.

Questions

• Is my understanding correct that Merkle-CRDTs would not tolerate Byzantine behaviour?
• Does Ambients give any guarantees against Byzantine behaviour or are those inherited from the underlying layer (blockchain, Merkle-CRDT etc.)?

[haadcode]

Agreed, it would be great to clarify the assumptions as now they're implicit in the paper.

Let's build the knowledge of the assumptions here in order to help creating a PR.

The base consistency level of ambients is eventual consistency, so you're right in your understanding that byzantine behaviour is something that needs to be handled separately. This can happen either at the execution environment level (the log, eg. using a blockchain as the log) or on the application level (eg. a consensus protocol compiled to an Ambients program, and using eg. OrbitDB as the log).

re-ordering of messages

Due to the log requirements (and the log being a Merkle-DAG), messages can be sent and received out of order. The log (eg. Merkle-CRDT) will guarantee deterministic ordering of the events regardless of the receive-order.

delayed

Same as above. Messages are sent and received asynchronously, ie. "eventually", so the same as above applies.

What other assumptions should we consider?