Contents
- Does a client send a transaction request to all the validators in the network?
- Does Sawtooth have a way to control what participants have access to what assets in the business network and under what conditions?
- What transaction processors are required?
- What does the Settings TP do?
- Can different Validator Nodes have different Transaction Processors running?
- How do I support multiple versions of a Transaction Processor?
- Can a Validator Node have multiple TPs (processes) running for the same TF?
- Why use round-robin if the transaction processors are identical?
- What happens if a validator receives a transaction but does not have a TP for it?
- How can I limit what Transaction Processors run on a Validator Node?
- Where do transactions originate?
- Can the same transaction appear in multiple blocks?
- What mechanism prevents a rogue TP from operating and corrupting data?
- What does this error mean: ``processor | [... DEBUG executor] transaction processors registered for processor type cryptomoji: 0.1`?
- What does this error mean:
processor | { AuthorizationException: Tried to get unauthorized address ...? - If you have a large file to store, is it best to just record the file hash and store the file offline?
- If I register a transaction processor to one validator, does the registration get transmitted to the other validators in a network?
- How do I add a transaction processor?
- How do I restrict what transaction processors are allowed?
- How do I add events to the transaction processor?
- What initial Sawtooth events are available?
- Why is the Apply method in the TP handler called twice?
- Do Transaction Processors run off-chain or on-chain?
- My TP throws an exception of type
InternalError, but theApplymethod gets stuck in an endless loop - I get this error when I try to set some Sawtooth settings:
Chain head is not set yet. Permit all
Warning
This FAQ was written by a non-expert so may contain both fiction and fact!
No, it would just need to send the batch to one validator, then that validator will broadcast the batch to the rest of its peers. If the validator is down, your connection attempt from the app would fail. The app could have error handling to try again (in a retry loop) or try another validator.
Does Sawtooth have a way to control what participants have access to what assets in the business network and under what conditions?
Blockchains, including Sawtooth, can be deployed as permissioned networks, wherein transactions are visible to the participants of the permissioned network, but not visible to the general public.
Just the Settings TP. All the other TPs are optional.
The settings-tp provides on-chain configs to be applied to the Sawtooth Validators, so that you can change operational parameters without restarting the validators or the whole sawtooth network. Also, you could right your own settings-tp, that stores the settings the same way but enforces different rules on how they are updated.
No. The set of TPs must be the same for all validator nodes in a Sawtooth network. The TP versions must also match across nodes--support the same set of ops. This is so the transaction and state validation will be successful.
You have two choices:
- A single TP can register itself to handle multiple versions. When the TP receives a transaction, it looks at the transaction's version field and decides how to handle it in the Apply() method.
- Multiple TPs, each handling a specific version.
In any case, all nodes need to support the same set of versions for a specific Transaction Family.
Yes, one or more TPs, handling the same or different Transaction Families, may be running and register with a validator. This is one way to achieve parallelism. Another way to achieve parallelism is to write a multi-threaded TP. The transactions are sent to transaction processors supporting the same transaction family in a round-robin fashion.
This is useful when the when the validator's parallel scheduler is used. Multiple transactions can be processed in parallel when the inputs/outputs do not conflict.
If a validator receives a transaction that it does not have a transaction processor for, the validator will wait until a TP connects that can handle that transaction. That validator would fall behind the rest on the network while it waits.
You can also limit which transactions are accepted on the network by setting
sawtooth.validator.transaction_families If that setting is not set, all transaction processors are accepted.
This setting is ignored in dev-mode consensus.
From the client. The client sends a transaction to a validator, in a batch with one or more transactions. The tranactions are sent to the validator, via the REST API, for the validator to add to the blockchain.
No. Each block has a unique set of transaction. A block is composed of batches, which is composed of transactions. Each transaction has a unique ID and appears only once in a blockchain. There may be, however, differences in ordering of blocks at a validator due to scheduling, transaction dependencies, etc.
The design is as such that rogue TPs can't harm legitimate TPs. When you run a network of validators, each validator has to have same version of TPs. If a rogue TP is modifying your TPs data, the same TP has to run in the rest of the validators in the network, to be able to affect the blockchain. The validator where the rogue TP is working will constantly fail state validations(merkle hashes will be different with rest of the network). Hence, the bigger the validator network, the more robust it is against such attacks.
What does this error mean: ``processor | [... DEBUG executor] transaction processors registered for processor type cryptomoji: 0.1`?
It means there is no transaction processor running for your transaction family.
What does this error mean: processor | { AuthorizationException: Tried to get unauthorized address ...?
It means a the transaction processor tried to access (get/put) a value not in the list of inputs/outputs. This occurs when a client submits a transaction with an inaccurate list of inputs/outputs.
If you have a large file to store, is it best to just record the file hash and store the file offline?
It depends on your use case. Storing data off-chain has a big downside. Although you can confirm it hasn't been tampered with with the on-chain hash, there is nothing stopping the file from disappearing. Also, how do you make sure everyone who needs the data can get to it?
If I register a transaction processor to one validator, does the registration get transmitted to the other validators in a network?
No. Your transaction processor must be deployed to all validators. All validators in a network must have the same set of transaction processors.
You just start it in for all the validator nodes. The TP needs to connect to tcp://localhost:4004 or, if you are using Docker, tcp://validator:4004
By default, any TP can be added to a node without special permission (other than network access). To restrict what TPs can be added to a validator, use sawset proposal create to set sawtooth.validator.transaction_families.
For details, see Configuring the List of Transaction Families at https://sawtooth.hyperledger.org/docs/core/releases/latest/app_developers_guide/docker.html
In the TP code, call context.add_event().
This adds a an application-specific event.
In the client code (or other app for listening), subscribe to the event.
For details, see
https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture/events_and_transactions_receipts.html#events
Besides application-specific events, the Sawtooth default events are:
sawtooth/commit-block- Committed block information: block ID, number, sate root hash, and previous block ID
sawtooth/state-delta- All state changes that occurred for a block at a specific address
That is by design. It can be called more than twice. For that rason, the TP handler must be deterministic (have the same output results given the same input).
Sawtooth TPs run off-chain, as a process (or processes).
InternalError is supposed to be a transient error (some internal fault like 'out of memory' that is temporary), and may succeed if retried.
The validator retries the transaction with the TP and results in a loop.
If the transaction is invalid, you probably want to raise an InvalidTransaction error instead.
This error has been seen when the ownerships are wrong. Try setting ownership as follows: chown sawtooth:sawtooth /var/lib/sawtooth /var/lib/sawtooth/*
© Copyright 2018, Intel Corporation.