Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Support ¶
type Support interface {
// Acquire implements semaphore-like acquire semantics
Acquire(ctx context.Context, n int64) error
// Release implements semaphore-like release semantics
Release(n int64)
// Ledger returns the ledger associated with this validator
Ledger() ledger.PeerLedger
// 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(cid string) []string
// Capabilities defines the capabilities for the application portion of this channel
Capabilities() channelconfig.ApplicationCapabilities
}
Support provides all of the needed to evaluate the VSCC
type TxValidator ¶
implementation of Validator interface, keeps reference to the ledger to enable tx simulation and execution of vscc
func NewTxValidator ¶
func NewTxValidator(chainID string, support Support, sccp sysccprovider.SystemChaincodeProvider, pm PluginMapper) *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:
- to keep the approach simple, the committer thread enqueues all transactions in the block and then moves on to reading the results.
- 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.
Source Files