tx

type ChannelConfig ¶

type ChannelConfig struct {
}

ChannelConfig gives handle to the channel config

type Envelope ¶

type Envelope struct {
	// SignedBytes contains the marshalled common.Payload in the envelope
	SignedBytes []byte
	// Signature contains the creator's signature over the SignedBytes
	Signature []byte
	// Data contains the opaque Data bytes in the common.Payload
	Data []byte
	// ChannelHeaderBytes contains the marshalled ChannelHeader of the common.Header
	ChannelHeaderBytes []byte
	// ChannelHeaderBytes contains the marshalled SignatureHeader of the common.Header
	SignatureHeaderBytes []byte
	// ChannelHeader contains the ChannelHeader of this envelope
	ChannelHeader *common.ChannelHeader
	// SignatureHeader contains the SignatureHeader of this envelope
	SignatureHeader *common.SignatureHeader
}

Envelope contains data of the common.Envelope; some byte fields are already unmarshalled to structs and we preserve the unmarshalled version so as to not duplicate the unmarshalling work. Still, given the non-deterministic nature of protobufs, we preserve their original byte representation so that the tx processor may for instance verify signatures or perform bitwise operations on their original representation.

type InvalidErr ¶

type InvalidErr struct {
	ActualErr      error
	ValidationCode peer.TxValidationCode
}

InvalidErr is intended to be used by a ProcessorCreator or a Processor to indicate that the transaction is found to be invalid

func (e *InvalidErr) Error() string

func (e *InvalidErr) Format(s fmt.State, verb rune)

type KeyValueItr ¶

type KeyValueItr struct {
	BackingItr keyValueItr
}

KeyValueItr helps iterates over the results of a range scan query

func (i *KeyValueItr) Close()

func (i *KeyValueItr) Next() (*statedata.KeyValue, error)

type Processor ¶

type Processor interface {
	Preprocess(latestChannelConfig *ChannelConfig) error
	Process(state *State, proposedWrites *statedata.ProposedWrites) error
	Done()
}

Processor contains logic for processing a transaction on the committing peer. One instance of a Processor is created for each transaction via `NewProcessor` function on the corresponding `ProcessorCreator`.

On a Processor, the first a `Preprocess` function is invoked and then the `Process` function is invoked. The `Preprocess` function is invoked exactly once however, this may be invoked in parallel on different instances of Processors. The function `Process` is invoked one by one on the `Processors` in the order in which the associated transactions appear in the block. The `State` passed to the `Process` function represents the world state for the channel as of preceding valid transaction in the block. For the purpose of efficiency (e.g., speculative execution), this function can be invoked more than once and hence this function should not preserve anything in the form of instance variables. Eventually, the function `Done` is invoked when the `Processor` has been used so as to indicate that the `Processor` can release any resources held. This invocation could be because of a successful invocation to the `Process` function or because the associated transaction is found to be invalid at any stage during the process (e.g., concurrency conflict with other transactions). If the `Processor` finds the transaction to be invalid at any stage, the error returned by the functions `PreProcess` and `Process` should be of type `InvalidErr`

The intent is to support different transaction types via interface Processor such as pure endorser transactions, pure post-order transactions, and a mixed transaction - e.g., a transaction that combines an endorser transaction and and a post-order transaction (say, a token transaction).

Below is the detail description of the semantics of the function `Process` In order to process a transaction on a committing peer, we first evaluate the simulated readwrite set of the transaction (returned by the function `NewProcessor` on the corresponding `ProcessorCreator`). If the simulated part is found to have a concurrency conflict with one or more preceding valid transactions (either a preceding transaction in the same block or in a preceding block), we mark the transaction invalid. However, if simulated part of the transaction is found to be conflict free, this is assumed that the transaction has logically started executing during commit time and has produced the writes present in the simulated part of the transaction. In this case, the transaction processing is continued from this point on and the `Process` function gives a chance to the `Processor` to complete the transaction processing. Via the `Process` function, the transaction processor can perform reads/writes to the state passed to this function.

Following is an illustration how the Processor is potentially expected be implemented for the transaction type "ENDORSER_TRANSACTION".

1. Preprocess function - Verifies the signatures and keeps the identities in internal state
2. Process function - Reads and evaluates endorsement policies that are applicable to the transactions writes. The parameter "proposedWrites" to the Process function, contains the data items are intended writes by the processing of the simulatedRWSet. The endorser transaction processor can load the applicable endorsement policies (such as chaincode or key-based) and returns an error of type InvalidErr if the endorsement policy is not satisfied.

type ProcessorCreator ¶

type ProcessorCreator interface {
	NewProcessor(txenv *Envelope) (processor Processor, simulatedRWSet [][]byte, err error)
}

ProcessorCreator creates a new instance of a processor of a particular transaction type. In addition, this function also returns zero or more simulated readwrite sets that may be present in the transaction if the transaction type supports enclosing of these. There is expected to be one to one mapping between a supported transaction type and the corresponding implementation of this interface. The transaction envelope passed to the function `NewProcessor` is guaranteed to be of the associated transaction type. If the ProcessCreator finds the transaction envelop to be invalid the err returned by this function should be of type `InvalidErr`

type PvtdataSourceHinter ¶

type PvtdataSourceHinter interface {
	PvtdataSource() [][]byte
}

PvtdataSourceHinter is an optional interface that a `Processor` implements to return the peers (identity bytes, e.g., certs) that could be the potential source for the private data associated with the transaction

type ReadHinter ¶

type ReadHinter interface {
	ReadHint(potentialWrites *statedata.WriteHint) *statedata.ReadHint
}

ReadHinter is an optional interface that a `Processor` implementation is encouraged to implement if the `Processor` can give any hints about what data items it would potentially read during its processing. This helps in pre-fetching/bulkloading the data in order to boost the performance For instance, the `Processor` implementation for the endorser transactions is expected to give hint about the endorsement policies based on the chaincode/collection/keys present in the "potentialWrites" parameter (which in turn are derived from the simulated readwrite set present in the transaction envelope) If a `Processor` implements this interface, the function `ReadHint` also gets the same treatment as the function `PreProcess` i.e., this is invoked before invoking function `Process` and exactly once and may be invoked in parallel on different instances of Processors. Note that the Preprocess and ReadHint functions on a Processor can get invoked in parallel

type ReprocessReadHinter ¶

type ReprocessReadHinter interface {
	ReprocessReadHint(potentialWrites *statedata.WriteHint) *statedata.ReadHint
}

ReprocessReadHinter is an optional interface that a `Processor` may choose to implement if it implements Reprocessor. This is similar to as a processor may implement the ReadHinter interface albiet this gets invoked only if Reprocessor is used for processing the transaction

type Reprocessor ¶

type Reprocessor interface {
	Reprocess(state *State, latestChannelConfig *ChannelConfig, proposedWrites *statedata.ProposedWrites)
}

Reprocessor is an optional interface that a `Processor` is encouraged to implement if a a significant large number of transactions of the corresponding type are expected to be present and validation of the transaction is significantly resource consuming (e.g., signature matching/crypto operations) as compare to manipulating the state. The main context in which the function in this interface is to be invoked is to rebuild the ledger constructs such as statedb and historydb from the blocks that has already been processed in the past. For instance, if the statedb is dropped and it is to be rebuilt, fabric will only use function in this interface (if implemented) instead of the function in the Processor interface. The function in this interface can safely assume that only transaction that are processed using this were found to be valid earlier (when Processor interface was used for processing the transaction for the first time) and hence, this function can skip any validation step and can just manipulate the state. However, if there is no significant difference in the resource consumption, there is no value in implementing this interface and the regular functions in the Processor interface would be invoked

type State ¶

type State struct {
	BackingState state
}

State exposes functions that helps a `Processor` in retrieving the latest state The `State` passed to the `Process` function represents the world state for the channel as of commit of the preceding valid transaction in the block

func (s *State) GetPrivateDataMetadataByHash(ns, coll string, keyHash []byte) (map[string][]byte, error)

func (s *State) GetState(ns, key string) ([]byte, error)

func (s *State) GetStateMetadata(ns, key string) (map[string][]byte, error)

func (s *State) GetStateRangeScanIterator(ns, startKey, endKey string) (*KeyValueItr, error)

func (s *State) SetState(ns, key string, value []byte) error

func (s *State) SetStateMetadata(ns, key string, metadata map[string][]byte) error