Skip to content

Commit

Permalink
Merge pull request #105 from giuliop/lsig-size-pooling
Browse files Browse the repository at this point in the history
Add logicsig size pooling in transaction groups
  • Loading branch information
giuliop authored Nov 14, 2024
2 parents 8774fcb + 071f781 commit ecf2c60
Show file tree
Hide file tree
Showing 2 changed files with 21 additions and 13 deletions.
20 changes: 12 additions & 8 deletions dev/TEAL.md
Original file line number Diff line number Diff line change
Expand Up @@ -148,14 +148,18 @@ of a contract account.
transaction against the contract account is for the program to
approve it.

The bytecode plus the length of all Args must add up to no more than
1000 bytes (consensus parameter LogicSigMaxSize). Each opcode has an
associated cost, usually 1, but a few slow operations have higher
costs. Prior to v4, the program's cost was estimated as the static sum
of all the opcode costs in the program (whether they were actually
executed or not). Beginning with v4, the program's cost is tracked
dynamically, while being evaluated. If the program exceeds its budget,
it fails.
The size of a Smart Signature is defined as the length of its bytecode
plus the length of all its Args. The sum of the sizes of all Smart
Signatures in a group must not exceed 1000 bytes times the number of
transactions in the group (1000 bytes is defined in consensus parameter
`LogicSigMaxSize`).

Each opcode has an associated cost, usually 1, but a few slow operations
have higher costs. Prior to v4, the program's cost was estimated as the
static sum of all the opcode costs in the program (whether they were
actually executed or not). Beginning with v4, the program's cost is
tracked dynamically, while being evaluated. If the program exceeds its
budget, it fails.

The total program cost of all Smart Signatures in a group must not
exceed 20,000 (consensus parameter LogicSigMaxCost) times the number
Expand Down
14 changes: 9 additions & 5 deletions dev/ledger.md
Original file line number Diff line number Diff line change
Expand Up @@ -490,7 +490,7 @@ which can be encoded as a msgpack struct:
- The number of digits after the decimal place to be used when displaying the
asset, encoded with msgpack field `dc`. A value of 0 represents an asset
that is not divisible, while a value of 1 represents an asset divisible into
into tenths, 2 into hundredths, and so on. This value must be between 0 and
into tenths, 2 into hundredths, and so on. This value must be between 0
and 19 (inclusive) ($2^{64}-1$ is 20 decimal digits).

- Whether holdings of that asset are frozen by default, a boolean flag encoded
Expand Down Expand Up @@ -638,9 +638,9 @@ specific fashion:
In more detail, let $r$ be the last round in which a transaction touched account $I$ (and therefore all pending rewards were added to it). Consider the following quantities, as defined in the [Account State](#account-state):

- The raw balance $a_I$ of account $I$ at round $r$ is its total balance on that round.
- The rewards base $a'_I$ is meant to capture the total rewards that were allocated to all accounts upto round $r$, expressed as a fraction of the total stake (with limited precision as described below).
- The rewards base $a'_I$ is meant to capture the total rewards that were allocated to all accounts up to round $r$, expressed as a fraction of the total stake (with limited precision as described below).

Given these two quantities, the normalized balance of an online account $I$ is $a_I/(1+a'_I)$. For example, if the total amount of rewards distributed upto round $r$ is 20% of the total stake, then the normalized balance is $a_I/1.2$.
Given these two quantities, the normalized balance of an online account $I$ is $a_I/(1+a'_I)$. For example, if the total amount of rewards distributed up to round $r$ is 20% of the total stake, then the normalized balance is $a_I/1.2$.

To limit the required precision in this calculation, the system uses a parameter $ru$ that specifies the rewards-earning unit, namely accounts only earn rewards for a whole number of $ru$ microAlgos. (Currently $ru=1,000,000$, so the rewards-earning unit is one Algo.)

Expand Down Expand Up @@ -1155,7 +1155,7 @@ If the sum of the fees paid by the transactions in a transaction group is less t

If the sum of the lengths of the boxes denoted by the box references in a
transaction group exceeds 1,024 times the total number of box
referencess in the transaction group, then the block is invalid. Call
references in the transaction group, then the block is invalid. Call
this limit the _I/O Budget_ for the group. Box references with an
empty name are counted toward the total number of references, but add
nothing to the sum of lengths.
Expand All @@ -1165,7 +1165,11 @@ modification) in a transaction group exceeds the I/O Budget of the
group at any time during evaluation (see [ApplicationCall Transaction
Semantics]), then the block is invalid.

Beyond the TxGroup, MinFee, and Box size checks, each transaction in a
If the sum of the lengths of all the logic signatures and their arguments
in a transaction group exceeds the number of transactions in the group times
1000 bytes (consensus variable `MaxLogicSigSize`), then the block in invalid.

Beyond the TxGroup, MinFee, Box size, and LogicSig size checks, each transaction in a
group is evaluated separately and must be valid on its own, as
described below in the [Validity and State Changes] section. For
example, an account with balance 50 could not spend 100 in transaction
Expand Down

0 comments on commit ecf2c60

Please sign in to comment.