The single-writer property and the content-hash chaining [10] of the logs make it very hard for a malicious user or storage node to insert a new log record or to modify an existing log record without the change being detected. To prevent version rollback attacks, public-key blocks contain version timestamps. When reading a public-key block (e.g., a loghead) from the store, clients attempt to read all k replicas of the block, and use the authentic replica with the most recent timestamp. When reading content-hash blocks or certificate blocks, it is sufficient to use any authentic replica.
Of great concern is the durability of stored messages. It depends on the failure independence of the replica node sets and an appropriate choice of replication factor, relative to the failure rate of individual nodes. POST's scoped insertion into local overlays greatly eases the assessment of failure independence and node failure rates, because all nodes are under some level of joint administrative control.
Organizations that run a local overlay should ensure that nodes are spread over different buildings, if not different sites. To reduce the risk of correlated failures due to security attacks, there should be sufficient heterogeneity in hardware and software. This can be difficult to ensure due to most organizations' monoculture approach to systems administration. However, risks from common virus attacks can be greatly reduced by running the POST daemon with reduced system privileges under its own user identifier. Thus, a compromised POST daemon has insufficient privileges to cause harm to the rest of the system. Likewise, other compromised user applications cannot attack POST's local file store.
Pastry's secure routing mechanism provides an effective defense against denial-of-service attacks against the overlay, both from within and outside [2]. Attacks aimed at filling the store can be thwarted with relative ease due to the use of local overlays. Since object insertions are allowed only within a local overlay, it is possible to track, identify and reprimand offenders within an organization.
Single-writer logs are the only mechanism used to maintain mutable state in POST. Their use avoids the cost and complexity of a general byzantine fault-tolerant replicated state machine. We are confident that POST's restricted mechanism for mutable state is flexible enough for applications like email, news, instant messaging and calendaring. The logs are efficient in cooperative applications, where insertions occur at a rate typical of human user actions.
Some cooperative applications may require a more flexible mechanism for maintaining mutable state. To support such applications, the authors at LIP6 are currently investigating additional, byzantine fault-tolerant mechanisms for maintaining multi-writer, mutable state.