|
|
@@ -44,10 +44,12 @@ Such a ledger lends itself to many use-cases including:
|
|
|
|
|
|
Since each account state links to it's previous state similar to how blocks link in a blockchain, accounts can be used to secure "embedded side-chains" (or **embedded-chains** for short).
|
|
|
|
|
|
-Under this interpretation, the PASA history serves as an embedded blockchain where each account state serves as a "block header". The Account Seal serves as the link to the previous "block header". The [Account Data][1] serves as the "merkle-root" to the block contents. The security of the blockchain is derived transitively from the SafeBox's [aggregated Proof-of-Work][2] which secures the PASA. This means **no addtional** Proof-of-Work or Proof-of-Stake is required to secure these embedded blockchains.
|
|
|
+Under this interpretation, the chain of account states (or a PASA-Chain) is used to embed a blockchain that is then consumed by a layer-2 network to determine a decentralized consensus for a layer-2 application. Since the ledger of messages is reliable, layer-2 nodes need only process the messages that comply with layer-2 consensus rules and ignore the ones that don't. All layer-2 nodes will always remain in consensus with each other, yet be independent of each other, since they only depend on the validity of the track of mesages stored in the PASA-Chain.
|
|
|
|
|
|
In essence, PascalCoin's Proof-of-Work is enough to secure millions of blockchains (1 for each account) at no extra financial or computational cost. An astonishing result, and the first of it's kind for any cryptocurrency.
|
|
|
|
|
|
+See [Embedded Chain Specification](#embedded-chain-specification) for more details.
|
|
|
+
|
|
|
### PASA as a Decentralised Finite-State-Machine
|
|
|
|
|
|
With the introduction of [DATA operations][4] in V4, a historical sequence of DATA operations can serve as a state-transition audit-log of any programmatic workflow.
|
|
|
@@ -98,8 +100,8 @@ end;
|
|
|
When an Account A is mutated by an operation O, the following rule must be applied **before** the mutation:
|
|
|
|
|
|
```
|
|
|
-A.Seal = HASH( AccountToRawBytes(A) ++ OPID(O) )
|
|
|
- where
|
|
|
+A.Seal = HASH( AccountToRawBytes( A ) ++ OPID(O) )
|
|
|
+ where
|
|
|
HASH( X ) = RIPEMD160( SHA2_256 ( X ) )
|
|
|
AccountToRawBytes ( X ) = account X serialized as an LE byte array as per network protocol
|
|
|
OPID(X) = RIPEMD160( operation X serialized as an LE byte array as per network protocol )
|
|
|
@@ -118,6 +120,72 @@ OPHASH = [BLOCK NUMBER] ++ [SIGNER ACCOUNT] ++ [N_OPERATION] ++ [OPID]
|
|
|
OPID: (20 bytes) - the RIPEMD160 of RAW OPERATION DATA this is the equivalent of a TXID in Bitcoin).
|
|
|
```
|
|
|
|
|
|
+### Seal Proofs
|
|
|
+
|
|
|
+In order to prove an prior account state is valid, the user needs a copy of that account state, and a list of hash-pairs from that state to the current state.
|
|
|
+
|
|
|
+```pascal
|
|
|
+ TStateProof = record
|
|
|
+ AccountState : TAccount;
|
|
|
+ OPID : TBytes[20]
|
|
|
+ end;
|
|
|
+
|
|
|
+ TAccountProof = array of StateProof;
|
|
|
+
|
|
|
+ function IsValidAccountProof(Proof : TAccountProof) : Boolean;
|
|
|
+ begin
|
|
|
+ if (proof[Length(proof) - 1].AccountState = SafeBox.GetAccount(account.Number)) AND IsValidProofChain(Proof) then
|
|
|
+ return true;
|
|
|
+ return false;
|
|
|
+ end
|
|
|
+
|
|
|
+ function IsValiProofChain( Proof : TAccountProof ) : Boolean;
|
|
|
+ begin
|
|
|
+ // validate in reverse
|
|
|
+ for i := Length(proof) - 1 downto 1 do begin
|
|
|
+ if proof[i].AccountState.Seal <> CalculateSeal( proof[i - 1] ) then
|
|
|
+ return false; // proof invalid at i - 1
|
|
|
+ end
|
|
|
+ return true;
|
|
|
+ end;
|
|
|
+
|
|
|
+ function CalculateSeal(proofLink : TStateProof ) : TBytes[32]
|
|
|
+ begin
|
|
|
+ return RIPEMD160 ( SHA2_256 ( Array.Join( SerializeAccount ( proofLink.AccountState ) , proofLink.OPID ) ) );
|
|
|
+ end
|
|
|
+
|
|
|
+ function SerializeAccount(account : TAccount) : TBytes;
|
|
|
+ begin
|
|
|
+ // ... as per network protocol
|
|
|
+ end
|
|
|
+```
|
|
|
+
|
|
|
+### Embedded-Chain Specification
|
|
|
+
|
|
|
+There are many methods to embed a blockchain inside a PASA chain, the general idea is to store the block-header and it's content-root inside the operation (or account state) and to depend on the Account Seal as the "chain mechanism".
|
|
|
+
|
|
|
+In particular, by tracking an account state A and it's mutating operation O, an embedded blockchain can be defined as follows:
|
|
|
+
|
|
|
+1. (A, O) = an embedded block
|
|
|
+2. A.Seal = pointer to previous embedded block
|
|
|
+3. O.Data = block-header (contains merkle-root for (4))
|
|
|
+4. Block contents distributed on layer-2 network
|
|
|
+
|
|
|
+Some differences between embedded-chains vs traditional blockchain are:
|
|
|
+* embedded chains never fork and are guaranteed to be linear
|
|
|
+* embedded blocks can are not mined, they are created by anyone willing to pay the network fee
|
|
|
+* embedded blocks can be created reliably at high-frequency without orphan rate risk
|
|
|
+* embedded chains can contain invalid blocks but these are only **ignored** by the layer-2 nodes, not orphaned
|
|
|
+* embedded chains do not store any block data, only a hash commitment to the block data which is distributed separately
|
|
|
+* embedded chains are validated purely by layer-2 consensus rules
|
|
|
+* embedded chains do not require any Proof-of-Work or Proof-of-Stake, they are secured by Layer-1 proof-of-work and carry the same security
|
|
|
+
|
|
|
+#### Spam Attack
|
|
|
+
|
|
|
+Embedded chains are susceptible to "spam-attack" scenario where a malicious actor attempts to flood the embedded-chain with invalid blocks (at cost). This attack would simply comprise of sending many operations to the target account which are not valid layer-2 embedded blocks, but which alter the account state. This is not a big issue if layer-2 nodes have a mechanism to rapidly detect and reject these invalid opeations/embedded blocks. This is a concern for layer-2 protocol designers but specifically, but general solutions which can be employed include:
|
|
|
+1. Use of data operations for declare embedded blocks, instead of other operations. The type field can be used to filter accidental/malformed transactions and for rapid block number sequencing.
|
|
|
+2. For malicous spam operations, merkle-proofs can be employed to detect and reject large invalid embdded-blocks (similar to "big block" scenario for traditional UTXO blockchains).
|
|
|
+
|
|
|
## Rationale
|
|
|
|
|
|
Simple and powerful extension that yields tremendous value, for virtually no cost. No brainer update.
|
Ugochukwu Mmaduekwe