Sweet Onion is a collection of augmentations to the flow protocol and ecosystem which attempts to mitigate transaction-driven attacks such as spamming, multiple inclusion, etc. These changes can be done in many steps and over a long range of time, the goal of this doc is to look at all these changes from a holistic point of view and make sure these changes are comprehensive and can cover all or majority of attacks when all are done. summary of changes are:

• collection nodes deduplicate transactions by PayloadHash (which naturally would mean no duplicated TxHash)
• collection nodes verify signatures of the payer and check the payer account is not on-hold
• account key revoking includes a delayed activating for payer signatures, so collection nodes have time to receive key events
• as long as the payer's signature is valid, the payer has to pay for inclusion fees
• the payer has to keep a soft minimum balance otherwise execution nodes would emit an event and describe the payer as an account with low-balance
• while collection nodes are still processing on-hold events, the payer still pays the inclusion fees even if it goes below the payer min balance (balance would be checked at the start of tx and tx would fail anyway in this case).
• payer be responsible for sequence number validity and anything related to the payload (e.g. pars-ability of scripts, etc)

Background Information

Transaction format (right now)

// Payload captures an intention of a transaction
// what all the authorizers would agree and sign about
// and would expire after X number of blocks if its not included by then
type Payload struct{

	// A reference to a previous block
	// A transaction is expired after specific number of blocks (defined by network) counting from this block
	ReferenceBlockID Identifier

	// the transaction script as UTF-8 encoded Cadence source code
	Script []byte

	// arguments passed to the Cadence transaction
	Arguments [][]byte

	// Max amount of computation which is allowed to be done during this transaction
	GasLimit uint64

	// Account key used to propose the transaction
	ProposalKey ProposalKey

	// Account that pays for this transaction fees
	Payer Address

	// A ordered (ascending) list of addresses that scripts will touch their assets (including payer address)
	// Accounts listed here all have to provide signatures
	// Each account might provide multiple signatures (sum of weight should be at least 1)
	// If code touches accounts that is not listed here, tx fails
	Authorizers []Address
}

type Envelope struct {
	// all the content of the payload
	Payload

	// List of account signatures excluding signature of the payer account
	PayloadSignatures []TransactionSignature
}

type TransactionBody struct {
	// all the content of the envelope
	Envelope

	// payer signature(s) over the envelope (payload + payload signatures)
	EnvelopeSignatures []TransactionSignature
}

Concepts

PayloadHash is the hash of the Payload; it represents the intention of the transaction, signed by all the authorizers

EnvelopeHash is the hash of the Envelope, ready to be executed and signed by the payer

TxHash is the hash of the TransactionBody; a commitment over the content of a transaction

TxID should represent a unique way to refer to a transaction by all parties and nodes, right now TxHash is used as TxID