Skip to content

Commit

Permalink
Merge branch 'main' into tla-docs-page
Browse files Browse the repository at this point in the history
  • Loading branch information
heidihoward authored Oct 23, 2023
2 parents 7d786f3 + c05d8be commit c2b7d35
Show file tree
Hide file tree
Showing 6 changed files with 17 additions and 7 deletions.
Binary file modified CCF-PAPER-VLDB-2023.pdf
Binary file not shown.
2 changes: 1 addition & 1 deletion doc/research/index.rst
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
Research
========

2023: `Confidential Consortium Framework: Secure Multiparty Applications with Confidentiality, Integrity, and High Availability <aka.ms/ccf-paper>`_
2023: `Confidential Consortium Framework: Secure Multiparty Applications with Confidentiality, Integrity, and High Availability <https://aka.ms/ccf-paper>`_
Confidentiality, integrity protection, and high availability, abbreviated to CIA, are essential properties for trustworthy data systems. The rise of cloud computing and the growing demand for multiparty applications however means that building modern CIA systems is more challenging than ever. In response, we present the Confidential Consortium Framework (CCF), a general-purpose foundation for developing secure stateful CIA applications. CCF combines centralized compute with decentralized trust, supporting deployment on untrusted cloud infrastructure and transparent governance by mutually untrusted parties.

CCF leverages hardware-based trusted execution environments for remotely verifiable confidentiality and code integrity. This is coupled with state machine replication backed by an auditable immutable ledger for data integrity and high availability. CCF enables each service to bring its own application logic, custom multiparty governance model, and deployment scenario, decoupling the operators of nodes from the consortium that governs them.
Expand Down
1 change: 1 addition & 0 deletions tla/consensus/MCccfraft.cfg
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@ CONSTANTS
Timeout <- MCTimeout
Send <- MCSend
ClientRequest <- MCClientRequest
SignCommittableMessages <- MCSignCommittableMessages
ChangeConfigurationInt <- MCChangeConfigurationInt
NotifyCommit <- MCNotifyCommit

Expand Down
8 changes: 8 additions & 0 deletions tla/consensus/MCccfraft.tla
Original file line number Diff line number Diff line change
Expand Up @@ -55,6 +55,14 @@ MCClientRequest(i) ==
/\ FoldSeq(LAMBDA e, count: IF e.contentType = TypeEntry THEN count + 1 ELSE count, 0, log[i]) < RequestLimit
/\ CCF!ClientRequest(i)

MCSignCommittableMessages(i) ==
\* The implementation periodically emits a signature for the current log, potentially causing consecutive
\* signatures. However, modeling consecutive sigs would result in a state space explosion, i.e., an infinite
\* number of states. Thus, we prevent a leader from creating consecutive sigs. We assume that consecutive
\* sigs will not violate safety or liveness.
/\ log[i] # <<>> => Last(log[i]).contentType # TypeSignature
/\ CCF!SignCommittableMessages(i)

\* CCF: Limit how many identical append entries messages each node can send to another
\* Limit number of duplicate messages sent to the same server
MCSend(msg) ==
Expand Down
1 change: 1 addition & 0 deletions tla/consensus/MCccfraftWithReconfig.cfg
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@ CONSTANTS
Timeout <- MCTimeout
Send <- MCSend
ClientRequest <- MCClientRequest
SignCommittableMessages <- MCSignCommittableMessages
ChangeConfigurationInt <- MCChangeConfigurationInt
NotifyCommit <- MCNotifyCommit

Expand Down
12 changes: 6 additions & 6 deletions tla/consensus/ccfraft.tla
Original file line number Diff line number Diff line change
Expand Up @@ -642,15 +642,15 @@ ClientRequest(i) ==
\* In CCF, the leader periodically signs the latest log prefix. Only these signatures are committable in CCF.
\* We model this via special ``TypeSignature`` log entries and ensure that the commitIndex can only be moved to these special entries.

\* Leader i signs the previous messages in its log to make them committable
\* This is done as a separate entry in the log that has a different
\* message contentType than messages entered by the client.
\* Leader i signs the previous entries in its log to make them committable.
\* This is done as a separate entry in the log that has contentType Signature
\* compared to ordinary entries with contentType Entry.
\* See history::start_signature_emit_timer
SignCommittableMessages(i) ==
\* Only applicable to Leaders with a log that contains at least one message
\* Only applicable to Leaders with a log that contains at least one entry.
/\ state[i] = Leader
\* The first log entry cannot be a signature.
/\ log[i] # << >>
\* Make sure the leader does not create two signatures in a row
/\ Last(log[i]).contentType # TypeSignature
\* Create a new entry in the log that has the contentType Signature and append it
/\ log' = [log EXCEPT ![i] = @ \o <<[term |-> currentTerm[i], contentType |-> TypeSignature]>>]
/\ committableIndices' = [ committableIndices EXCEPT ![i] = @ \cup {Len(log'[i])} ]
Expand Down

0 comments on commit c2b7d35

Please sign in to comment.