Skip to content

Latest commit

 

History

History
139 lines (111 loc) · 3.67 KB

cap-0002.md

File metadata and controls

139 lines (111 loc) · 3.67 KB
Raw

Preamble

CAP: 0002
Title: Transaction level signature verification 
Author: Nicolas Barry, Rafal Malinowski
Status: Final
Created: 2018-05-03
Discussion: https://github.com/stellar/stellar-core/issues/1464
Protocol Version: 10

Simple Summary

Make signature verification behave the same way pre and post consensus in order to make smart contracts easier to author.

Abstract

Perform signature verification (for each operation) before performing any of the transaction side effects.

This may still allow certain transactions to invalidate future transactions in the same transaction set, while allowing operations in a transaction to safely manipulate signers.

Motivation

Currently signatures are verified in two different ways:

  • when building a transaction set for consensus, verification is done without any of the operation side effects
  • when applying transactions post consensus, each operation checks again for signatures

The problem with this approach is that some operations may cause subsequent operations in the same transaction to fail, making crafting pre-signed transactions that manipulate multiple signers or weights very complicated (or impossible) to implement in the context of multiple operations within a transaction.

Specification

Transaction's doApply will be modified to perform in order:

  1. transaction level changes
    1. sequence number processing
    2. signature verification
      1. verify signatures for each operation
      2. removal of one time signatures
  2. operations processing, for each operation:
    1. validity checks (same as today except for the signature verification)
    2. side effects

Rationale

This approach makes signature verification behave the same way than how sequence numbers are now processed (in v10 of the protocol as per cap-0001).

Removal of one time signatures are done first in order to avoid introducing a new concept of "post transaction side effects" that are not currently modeled in the meta data.

Note that we could add this notion to protocol 10 as cap-001 has not been put in production yet but the added complexity doesn't seem to be necessary.

Backwards Compatibility

This change makes certain transaction succeed that are now failing.

There are probably no good use cases for those failures, so it is deemed safe.

Test Cases

Transactions that should now succeed:

change thresholds twice

// transaction that changes A thresholds twice
envelope:
{
    tx:
    {
        source: A,
        operations:
        [
            [ op: setOptionsOp, weigths: [1,1,2,3] ],
            [ op: setOptionsOp, weigths: [1,1,2,3] ]
        ]
    },
    signatures: [A]
}

Failing right now with opBAD_AUTH for second operation.

lower master weight twice

// A with weigths=[10,1,5,10]

// transaction that lowers master weight twice
envelope:
{
    tx:
    {
        source: A,
        operations:
        [
            [ op: setOptionsOp, masterWeight : 9 ],
            [ op: setOptionsOp, masterWeight : 8 ]
        ]
    },
    signatures: [A]
}

Failing right now with opBAD_AUTH for second operation.

remove signer and do something

// A with signers: {key: B, weight: 1}; weigths=[1,2,2,2]
envelope:
{
    tx:
    {
        source: A,
        operations:
        [
            // deletes B from signers
            [ op: setOptionsOp, signer : {key:B, w:0} ],
            [ op: setOptionsOp, homeDomain : "stellar.org" ]
        ]
    },
    signatures: [A, B]
}

Failing right now with opBAD_AUTH for second operation.

Implementation

Commit c9087d0cc4c0710c9129d473fcd22887c60e4653