mirror of
https://github.com/corda/corda.git
synced 2025-01-18 02:39:51 +00:00
Delete the notes directory, it is long since obsoleted by the wiki and the docs site.
This commit is contained in:
Mike Hearn
parent
e3cfe0ae49
commit
d6cdc8b8de
@ -1,195 +0,0 @@
|
||||
General design scratchpad
|
||||
|
||||
Do we need blocks at all? Blocks are an artifact of proof-of-work, which isn't acceptable on private block chains
|
||||
due to the excessive energy usage, unclear incentives model and so on. They're also very useful for SPV operation,
|
||||
but we have no such requirements here.
|
||||
|
||||
Possible alternative, blend of ideas from:
|
||||
|
||||
* Google Spanner
|
||||
* Hawk
|
||||
* Bitcoin
|
||||
* Ethereum
|
||||
* Intel/TCG
|
||||
|
||||
+ some of my own ideas
|
||||
|
||||
|
||||
|
||||
# Blockless operation
|
||||
|
||||
* A set of timestampers are set up around the world with clocks synchronised to GPS time (the most accurate clock
|
||||
available as it's constantly recalibrated against the US Naval Observatory atomic clock). Public timestampers
|
||||
are available already and can be easily used in the prototyping phase, but as they're intended for low traffic
|
||||
applications eventually we'd want our own.
|
||||
|
||||
There is a standard protocol for timestamp servers (RFC 3161). It appears to include everything that we might want
|
||||
and little more, i.e. it's a good place to start. A more modern version of it with the same features can be easily
|
||||
generated later.
|
||||
|
||||
* All transactions submitted to the global network must be timestamped by a recognised TSP (i.e. signed by a root cert
|
||||
owned by R3).
|
||||
|
||||
* Transactions are ordered according to these timestamps. They are assumed to be precise enough that conflicts where
|
||||
two transactions have actually equal times can ~never happen: a trivial resolution algorithm (e.g. based on whichever
|
||||
hash is lower) can be used in case that ever happens by fluke.
|
||||
|
||||
* If need be, clock uncertainty can be measured and overlapping intervals can result in conflict/reject states, as in
|
||||
Spanner's TrueTime. The timestamping protocol (RFC 3161) exposes clock uncertainty.
|
||||
|
||||
* Transactions are timestamped as a group. This ensures that if multiple transactions are needed to carry out a trade,
|
||||
individual transactions cannot be extracted by a malicious party and executed independently as the original bundle
|
||||
will always be able to win, when broadcast.
|
||||
|
||||
* Nodes listen to a broadcast feed of timestamped transactions. They know how to roll back transactions and replay
|
||||
new ones in case of conflict, but this is done independent of any block construct.
|
||||
|
||||
* Nodes that are catching up simply download all the transactions from peers that occur after the time they shut down.
|
||||
They can be sure they didn't miss any by asking peers to calculate a UTXO set summary at a given time and then
|
||||
verifying it against their own local calculations (this is slow, but shouldn't normally flag any issues so it can
|
||||
be done asynchronously).
|
||||
|
||||
* Individual transactions/UTXOs can specify time bounds, e.g. "30 seconds". A node compares a transaction timestamp
|
||||
to its own local clock and applies the specified bound to the local clock: if the transaction is out of bounds and
|
||||
the node isn't catching up, then it is dropped. This prevents people timestamping a malicious transaction X and
|
||||
keeping it private, then broadcasting a publicly timestamped transaction Y, then overriding Y with X long after the
|
||||
underlying trade has become irreversible. Because time bounds are specified on a _per transaction_ basis, it is
|
||||
arbitrarily controllable: traders that want very, very fast clearing can specify a small time boundary and it's up
|
||||
to them to ensure their own systems are capable of getting an accurate trusted timestamp and broadcasting it within
|
||||
that tight bound. Traders that care less, e.g. because the trade represents physical movement of real goods, can use
|
||||
a much larger time bound and get more robustness against transient network/hardware hiccups.
|
||||
|
||||
* Like in Ethereum, transactions can update stored state (contracts? receipts? what is the right term?)
|
||||
|
||||
This can be called transaction-chains. All transactions are public.
|
||||
|
||||
For political expedience, we may wish to impose a (not strictly necessary) block quantisation anyway, so the popular
|
||||
term 'block chain' can be applied and also for auditing/reporting convenience.
|
||||
|
||||
# Privacy
|
||||
|
||||
* Transactions can have two halves: the public side and the private side. The public side is a "normal" transaction that
|
||||
includes a program of sufficient power to verify various kinds of signatures and proofs. The optional private side
|
||||
is an arbitrary program which is executed by a third party. Various techniques are used to lower the trust required
|
||||
in the third parties. We can call these notaries.
|
||||
|
||||
* It's up to the contract designer to decide how much they rely on notaries - if at all. They are technically not
|
||||
required at all: the system would work (and scale) without them. But they can be used to improve privacy.
|
||||
|
||||
* Simplest "dummy" notary is just a machine that signs the output of the program to state it ran it properly. The notary
|
||||
is trusted to execute the program correctly and privately. The signature is checked by the public side. This allows
|
||||
traders to perform e.g. a Dutch auction with only the final results being reflected on the public network.
|
||||
|
||||
* Next best is an SGX based notary. This can provide both privacy and assurance that the code is executed correctly,
|
||||
assuming Intel is trustworthy. Note: it's a safe assumption that if R3 becomes very popular with financial networks,
|
||||
intelligence agencies will attempt to gain covert access to it given the NSA/GCHQ hacking of Western Union and clear
|
||||
interest in SWIFT data. Thus care must be used to ensure the (entirely unprovable) SGX computers are not interdicted
|
||||
during delivery.
|
||||
|
||||
* In addition, zero knowledge proofs can be considered as a supplement to SGX. They can give extra assurance against
|
||||
corrupted notaries calculating incorrect results. However, unlike SGX, they cannot reduce the amount of information
|
||||
the notary sees, and thus they are strictly a "backup". In addition they have _severe_ caveats, in particular, a
|
||||
complex and expensive setup phase that must be executed for each contract (in fact for each version of each contract),
|
||||
and execution of the private side is extremely slow.
|
||||
|
||||
This makes them suitable only for contracts that are basically finalised and in which the highest levels of assurance
|
||||
are required, and fast or frequent trading is not required. The technology may well improve over time.
|
||||
|
||||
* In some cases homomorphic encryption could be used as a privacy supplement to SGX.
|
||||
|
||||
# Scaling
|
||||
|
||||
* Global broadcast systems are frequently attacked for 'not scaling'. But this is an absolute statement in a world of
|
||||
tradeoffs: technically speaking the NASDAQ is a broadcast system as you can subscribe to data feeds via e.g. OPRA.
|
||||
Some of these feeds can reach millions of messages per second. Nonetheless, financial firms are capable of digesting
|
||||
them without issue. Even the largest feeds have finite traffic and predictable growth patterns.
|
||||
|
||||
* We can assume powerful hardware, as the primary users of this system would be financial institutions. There is no
|
||||
requirement to run on people's laptops, outside of testing/devnet scenarios. For instance it's safe to assume SSD
|
||||
based storage: we can simply tell institutions that want to get on the network to buy a proper server.
|
||||
|
||||
* There is no requirement for lightweight/mobile clients, unlike in Bitcoin.
|
||||
|
||||
* Transaction checking is highly parallelisable.
|
||||
|
||||
* Therefore, as long as transactions are kept computationally cheap, there should be no problem reaching even very high
|
||||
levels of traffic.
|
||||
|
||||
Conclusion: scaling in a Bitcoin style manner should not be a problem, even if high level languages like Java or Kotlin
|
||||
are in use.
|
||||
|
||||
# Programmability
|
||||
|
||||
* The public side of a transaction must use a globally agreed execution environment, like the EVM is for Ethereum.
|
||||
The private sides can run anything: as the public side checks a proof of execution of the private side, there is
|
||||
no requirement that the private side use any particular language or runtime.
|
||||
|
||||
* Inventing a custom VM and language doesn't make sense: there is only one special requirement that is different
|
||||
to most VMs and that's the ability to impose hard CPU usage limits. But existing VMs can be extended to deliver
|
||||
this functionality much more easily than entirely new VMs+languages can be created.
|
||||
|
||||
* For prototyping and possibly for production use, we should use the JVM:
|
||||
|
||||
* Sandboxing already available, easy to use
|
||||
* Several languages available, developers are familiar
|
||||
* If host environment also runs on the JVM, no time wasted on interop issues, see the Ethereum ABI issues
|
||||
* HotSpot already has a CPU/memory tracking API and can interrupt threads (but lacks the ability to hard shut down
|
||||
malicious code)
|
||||
* Code annotations can be used to customise whatever languages are used for contract-specific use cases.
|
||||
* Can be forced to run in interpreted mode at first, but if we need the extra performance later due to high traffic
|
||||
the JIT compiler will automatically make contract code fast.
|
||||
* Has industrial strength debugging/monitoring tools.
|
||||
* Banks are already deeply familiar with it.
|
||||
|
||||
|
||||
|
||||
# Transaction design
|
||||
|
||||
Use a vaguely bitcoin-like design with "states" which are consumed and generated by "contracts" (programs). Everyone
|
||||
runs the same programs simultaneously in order to verify state transitions. Transactions consist of input states,
|
||||
output states and "commands" which represent signed auxiliary inputs to the transitions.
|
||||
|
||||
|
||||
|
||||
------
|
||||
|
||||
# Useful technologies
|
||||
|
||||
FIX SBE is a very (very) efficient binary encoding designed for HFT:
|
||||
|
||||
http://real-logic.github.io/simple-binary-encoding/
|
||||
|
||||
It's mostly analogous to protocol buffers but imposes some additional constraints and has an uglier API, in return for
|
||||
much higher performance. It probably isn't useful during the prototyping phase. But it may be a useful optimisation
|
||||
later.
|
||||
|
||||
CopyCat is an implementation of Raft (similar to Paxos), as an embeddable framework. Raft/Paxos type algorithms are not
|
||||
suitable as the basis for a global distributed ledger due to tiny throughput, but may be useful as a subcomponent of
|
||||
other algorithms. For instance possibly a multi-step contract protocol could use Raft/Paxos between a limited number of
|
||||
counterparties to synchronise changes.
|
||||
|
||||
http://kuujo.github.io/copycat/user-manual/introduction/
|
||||
|
||||
|
||||
|
||||
------
|
||||
|
||||
|
||||
# Prototyping
|
||||
|
||||
Stream 1:
|
||||
|
||||
1. Implement a simple star topology for message routing (full p2p can come later). Ensure it's got a clean modular API.
|
||||
2. Implement a simple chat app on top of it. This will be useful later for sending commands to faucets, bots, etc.
|
||||
3. Add auto-update
|
||||
4. Design a basic transaction/transaction bundle abstraction and implement timestamping of the bundles. Make chat lines
|
||||
into "transactions", so they are digitally signed and timestamped properly.
|
||||
5. Implement detection of conflicts and rollbacks.
|
||||
|
||||
|
||||
|
||||
Stream 2: Design straw-man contracts and data structures (in Java or Kotlin) for
|
||||
|
||||
1. payments
|
||||
2. simplified bond auctions
|
||||
3. maybe a CDS
|
||||
@ -1,19 +0,0 @@
|
||||
# Simple payment
|
||||
|
||||
CashState:
|
||||
- Issuing institution
|
||||
- Deposit reference (pointer into internal ledger)
|
||||
- Currency code
|
||||
- Claim size (initial state = size of original deposit)
|
||||
- Public key of current owner
|
||||
|
||||
ExitCashState:
|
||||
- Amount to reduce claim size by
|
||||
- Signature signed by ownerPubKey
|
||||
|
||||
State transition function (contract):
|
||||
1. If input states contains an ExitCashState, set reduceByAmount=state.amount
|
||||
1. For all proposed output states, they must all be instances of CashState
|
||||
For all proposed input states, they must all be instances of CashState
|
||||
2. Sum claim sizes in all predecessor states. Sum claim sizes in all successor states
|
||||
3. Accept if outputSum == inputSum - reduceByAmount
|
||||
@ -1,19 +0,0 @@
|
||||
How to represent pointers to states in the type system? Opaque or exposed as hashes?
|
||||
|
||||
# Create states vs check states?
|
||||
|
||||
1. Derive output states entirely from input states + signed commands, *or*
|
||||
2. Be given the output states and check they're valid
|
||||
|
||||
The advantage of 1 is that it feels safer: you can't forget to check something in the output state by accident. On
|
||||
the other hand, then it's up to the platform to validate equality between the states (probably by serializing them
|
||||
and comparing bit strings), and that would make unit testing harder as the generic machinery can't give good error
|
||||
messages for a given mismatch. Also it means you can't do an equivalent of OP_RETURN and insert extra no-op states
|
||||
in the output list that are ignored by all the input contracts. Does that matter if extensibility/tagging is built in
|
||||
more elegantly? Is it better to prevent this for the usual spam reasons?
|
||||
|
||||
The advantage of 2 is that it seems somehow more extensible: old contracts would ignore fields added to new states if
|
||||
they didn't understand them (or is that a disadvantage?)
|
||||
|
||||
# What precisely is signed at each point?
|
||||
|
||||
Loading…
Reference in New Issue
Block a user