Susereum Transaction Family Specifications
The code-smell family provides a methodology for managing code smell functions.
The code-smell family handles the business logic to process Susereum's protocol which controls all operations related to code smells (load default configuration, propose new metrics, and vote for proposals).
Transactions within the code-smell family have a common format that helps to keep a consist structure between them.
- family_name: "code_smell"
- family_version: "1.0"
None
| type | id | data | state | date |
|---|---|---|---|---|
| code-smell | LargeClass | 500 | create | none |
The above table represents an example of a code smell transaction. Each column is separate by a comma.
- type: represent the type of transaction, the family could have three type of transactions code_smell, proposal, and vote.
- id: represent the transaction's id.
- data: represent the payload of each transaction.
- state: represent the state of a transaction on any given moment, a transaction could have different state throughout its cycle.
- date: represent the moment that a transaction was created, the time attribute is only use on transactions of type proposal.
code-smell family has several functions that can be used to send transactions and review those transactions within the chain.
default(self, wait=None)
Load default code smell configuration.
ARGS: None
propose(self, code_smells):
Propose a new code smell metrics.
ARGS: list of code smells.
vote(self, proposal_id, vote)
Vote for a proposal. (1=yes , 0=no)
ARGS: proposal id, vote value
list(self,type=None)
Return a list of transactions, the type defines which kind of transaction will be returned.
ARGS: type (type of transaction to list)
show(self, address)
Return a specific transaction.
ARGS: transaction address.
_check_votes(self, proposal_id, flag=None)
Return number of votes, checking votes can be used to review the current votes or to run a proposal validation.
ARGS: proposal id, flag
Initially, the transaction processor gets the current values of sawtooth.identity.allowed_keys from the state.
The public key of the transaction signer is checked against the values in the list of allowed keys. If it empty, no new transactions can be processed. If the transaction signer is not in the allowed keys the transaction is invalid.
If the transaction is loading a default configuration the current metrics and code smells will be pulled from the TOML configuration file ~/Susereum/Sawtooth/etc/code_smell.toml. Each code smell will be submitted to the Blockchain as an independent transaction.
If the transaction is proposing new metrics for the code smells, the user must send the complete list of code smells. Only one proposal can be active at a given moment. Proposals have a voting period and a vote threshold. If the voting period ends before meeting the threshold, the proposal will be accepted if at it has at least one vote. The voting period and threshold are defined in the configuration file.
If the transaction is setting a vote, the proposal must be active. If the threshold is met after the vote, then it triggers and update and recalculates the system’s health. See Susereum's Protocol for more details regarding the Susereum's protocol.
Although users can call _check_votes whenever they want. The function does not register a transaction into the block. The main purpose of the function is to have a cronjob, checking if the voting period of the active proposal is still valid or if further actions must be done.