sf.antelope.type.v1.Block

The unfiltered transactions in this block when NO filtering has been applied, (i.e. filtering_applied = false). When filtering has been applied on this block, (i.e. filtering_applied = true), this field will be set to nil and instead, the filtered_transactions will be populated with only filtered transactions.

Use the helper getter method Transactions() to automatically pick the correct field to use (unfiltered_transactions when filtering_applied == false and filtered_transactions when filtering_applied == true).

The unfiltered implicit transaction ops in this block when NO filtering has been applied, (i.e. filtering_applied = false). When filtering has been applied on this block, (i.e. filtering_applied = true), this field will be set to nil and instead, the filtered_implicit_transaction_ops will be populated with only filtered implicit transaction ops.

Use the helper getter method ImplicitTransactionOps() to automatically pick the correct field to use (unfiltered_implicit_transaction_ops when filtering_applied == false and filtered_implicit_transaction_ops when filtering_applied == true).

The unfiltered transaction traces in this block when NO filtering has been applied, (i.e. filtering_applied = false). When filtering has been applied on this block, (i.e. filtering_applied = true), this field will be set to nil and instead, the filtered_transaction_traces will be populated with only filtered transactions.

Use the helper getter method TransactionTraces() to automatically pick the correct field to use (unfiltered_transaction_traces when filtering_applied == false and filtered_transaction_traces when filtering_applied == true).

This replaces block_signing_key with a richer structure able to handle the weighted threshold multisig for block producers.

This can be downgraded to the old block_signing_key simply by taking the first key present in the list. This is of course simple and not accurate anymore in EOSIO 2.0 system where WTMSIG_BLOCK_SIGNATURES has been activated AND block producers starts signing blocks with more than one key.

See BlockSigningAuthority for further details

This replaces the old type ProducerSchedule for the active_schedule field. This was only a type change in EOSIO 2.0, the field's name remained the same.

This is the new schedule data layout which is richer than it's oldest counterpart. The inner element for a producer can then be composed with multiple keys, each with their own weight and the threshold required to accept the block signature.

Wheter or not a filtering process was run on this block. The filtering process sets to nil the unfiltered_transaction_traces to nil and populate the filtered_transaction_traces according to the filtering_include_filter_expr and filtering_exclude_filter_expr CEL expressions. A transaction will be present in the filtered_transaction_traces array if it matched the filtering_include_filter_expr and did NOT match the filtering_exclude_filter_expr.

Moreover, each matching action that brought the transaction to be in filtered_transaction_traces array will have a filtering_matched flag set on it to broadcast the fact that this action match the inclusion/exclusion list.

This flag controls all filtered_* and unfiltered_* elements on the Block structure and on substructures if present.

The filtered transaction traces in this block when filtering has been applied, (i.e. filtering_applied = true). This will be only the transaction trace that matched the include filter CEL expression and did NOT match the exclude filter CEL expression.

Use the helper getter method TransactionTraces() to automatically pick the correct field to use (unfiltered_transaction_traces when filtering_applied == false and filtered_transaction_traces when filtering_applied == true).

The filtered transactions in this block when filtering has been applied, (i.e. filtering_applied = true). This will be only the transactions that matched the include filter CEL expression and did NOT match the exclude filter CEL expression.

Use the helper getter method Transactions() to automatically the correct field (unfiltered_transaction when filtering_applied == false and filtered_transactions when filtering_applied == true).

The filtered implicit transaction ops in this block when filtering has been applied, (i.e. filtering_applied = true). This will be only the implicit transaction ops that matched the include filter CEL expression and did NOT match the exclude filter CEL expression.

Use the helper getter method ImplicitTransactionOps() to automatically the correct field (unfiltered_implicit_transaction_ops when filtering_applied == false and filtered_implicit_transaction_ops when filtering_applied == true).