txvalidator

Documentation

Index

• type ChannelPolicyManagerGetter
• type ChannelResources
• type Dispatcher
• type LedgerResources
• type PolicyManager
• type QueryExecutor
• type Semaphore
• type TxValidator
  • func NewTxValidator(channelID string, sem Semaphore, cr ChannelResources, ler LedgerResources, ...) *TxValidator
  • func (v *TxValidator) Validate(block *common.Block) error

Types

type ChannelPolicyManagerGetter

type ChannelPolicyManagerGetter interface {
	policies.ChannelPolicyManagerGetter
}

ChannelPolicyManagerGetter is the local interface that used to generate mocks for foreign interface.

type ChannelResources

type ChannelResources interface {
	// MSPManager returns the MSP manager for this channel
	MSPManager() msp.MSPManager

	// Apply attempts to apply a configtx to become the new config
	Apply(configtx *common.ConfigEnvelope) error

	// GetMSPIDs returns the IDs for the application MSPs
	// that have been defined in the channel
	GetMSPIDs() []string

	// Capabilities defines the capabilities for the application portion of this channel
	Capabilities() channelconfig.ApplicationCapabilities
}

ChannelResources provides access to channel artefacts or functions to interact with them

type Dispatcher

type Dispatcher interface {
	// Dispatch invokes the appropriate validation plugin for the supplied transaction in the block
	Dispatch(seq int, payload *common.Payload, envBytes []byte, block *common.Block) (error, peer.TxValidationCode)
}

Dispatcher is an interface to decouple tx validator and plugin dispatcher

type LedgerResources

type LedgerResources interface {
	// GetTransactionByID retrieves a transaction by id
	GetTransactionByID(txID string) (*peer.ProcessedTransaction, error)

	// NewQueryExecutor gives handle to a query executor.
	// A client can obtain more than one 'QueryExecutor's for parallel execution.
	// Any synchronization should be performed at the implementation level if required
	NewQueryExecutor() (ledger.QueryExecutor, error)
}

LedgerResources provides access to ledger artefacts or functions to interact with them

type PolicyManager

type PolicyManager interface {
	policies.Manager
}

type QueryExecutor

type QueryExecutor interface {
	ledger.QueryExecutor
}

QueryExecutor is the local interface that used to generate mocks for foreign interface.

type Semaphore

type Semaphore interface {
	// Acquire implements semaphore-like acquire semantics
	Acquire(ctx context.Context) error

	// Release implements semaphore-like release semantics
	Release()
}

Semaphore provides to the validator means for synchronisation

type TxValidator

type TxValidator struct {
	ChannelID        string
	Semaphore        Semaphore
	ChannelResources ChannelResources
	LedgerResources  LedgerResources
	Dispatcher       Dispatcher
	CryptoProvider   bccsp.BCCSP
}

TxValidator is the implementation of Validator interface, keeps reference to the ledger to enable tx simulation and execution of plugins

func NewTxValidator

func NewTxValidator(
	channelID string,
	sem Semaphore,
	cr ChannelResources,
	ler LedgerResources,
	lcr plugindispatcher.LifecycleResources,
	cor plugindispatcher.CollectionResources,
	pm plugin.Mapper,
	channelPolicyManagerGetter policies.ChannelPolicyManagerGetter,
	cryptoProvider bccsp.BCCSP,
) *TxValidator

NewTxValidator creates new transactions validator

func (*TxValidator) Validate

func (v *TxValidator) Validate(block *common.Block) error

Validate performs the validation of a block. The validation of each transaction in the block is performed in parallel. The approach is as follows: the committer thread starts the tx validation function in a goroutine (using a semaphore to cap the number of concurrent validating goroutines). The committer thread then reads results of validation (in orderer of completion of the goroutines) from the results channel. The goroutines perform the validation of the txs in the block and enqueue the validation result in the results channel. A few note-worthy facts:

1. to keep the approach simple, the committer thread enqueues all transactions in the block and then moves on to reading the results.
2. for parallel validation to work, it is important that the validation function does not change the state of the system. Otherwise the order in which validation is perform matters and we have to resort to sequential validation (or some locking). This is currently true, because the only function that affects state is when a config transaction is received, but they are guaranteed to be alone in the block. If/when this assumption is violated, this code must be changed.