Feature/contract to contract

cmd/opdoc/opdoc.go

@@ -147,6 +147,11 @@ func appParamsFieldsMarkdown(out io.Writer) {
 	fieldSpecsMarkdown(out, logic.AppParamsFieldNames, logic.AppParamsFieldSpecByName)
 }
 
+func acctParamsFieldsMarkdown(out io.Writer) {
+	fmt.Fprintf(out, "\n`acct_params_get` Fields:\n\n")
+	fieldSpecsMarkdown(out, logic.AcctParamsFieldNames, logic.AcctParamsFieldSpecByName)
+}
+
 func ecDsaCurvesMarkdown(out io.Writer) {
 	fmt.Fprintf(out, "\n`ECDSA` Curves:\n\n")
 	fieldSpecsMarkdown(out, logic.EcdsaCurveNames, logic.EcdsaCurveSpecByName)
@@ -239,6 +244,8 @@ func opToMarkdown(out io.Writer, op *logic.OpSpec) (err error) {
 		assetParamsFieldsMarkdown(out)
 	} else if op.Name == "app_params_get" {
 		appParamsFieldsMarkdown(out)
+	} else if op.Name == "acct_params_get" {
+		acctParamsFieldsMarkdown(out)
 	} else if strings.HasPrefix(op.Name, "ecdsa") {
 		ecDsaCurvesMarkdown(out)
 	}

config/consensus.go

@@ -282,7 +282,9 @@ type ConsensusParams struct {
 	// maximum sum of the lengths of the key and value of one app state entry
 	MaxAppSumKeyValueLens int
 
-	// maximum number of inner transactions that can be created by an app call
+	// maximum number of inner transactions that can be created by an app call.
+	// with EnableInnerTransactionPooling, limit is multiplied by MaxTxGroupSize
+	// and enforced over the whole group.
 	MaxInnerTransactions int
 
 	// should inner transaction limit be pooled across app calls?
@@ -443,8 +445,8 @@ var MaxStateDeltaKeys int
 // any version, used only for decoding purposes. Never decrease this value.
 var MaxLogCalls int
 
-// MaxInnerTransactions is the maximum number of inner transactions that may be created in an app call.
-var MaxInnerTransactions int
+// MaxInnerTransactionsPerDelta is the maximum number of inner transactions in one EvalDelta
+var MaxInnerTransactionsPerDelta int
 
 // MaxLogicSigMaxSize is the largest logical signature appear in any of the supported
 // protocols, used for decoding purposes.
@@ -513,7 +515,7 @@ func checkSetAllocBounds(p ConsensusParams) {
 	// There is no consensus parameter for MaxLogCalls and MaxAppProgramLen as an approximation
 	// Its value is much larger than any possible reasonable MaxLogCalls value in future
 	checkSetMax(p.MaxAppProgramLen, &MaxLogCalls)
-	checkSetMax(p.MaxInnerTransactions, &MaxInnerTransactions)
+	checkSetMax(p.MaxInnerTransactions*p.MaxTxGroupSize, &MaxInnerTransactionsPerDelta)
 	checkSetMax(p.MaxProposedExpiredOnlineAccounts, &MaxProposedExpiredOnlineAccounts)
 }
 

data/transactions/logic/README.md

@@ -1,7 +1,7 @@
 # The Algorand Virtual Machine (AVM) and TEAL.
 
 The AVM is a bytecode based stack interpreter that executes programs
-asscoiated with Algorand transactions. TEAL is an assembly language
+associated with Algorand transactions. TEAL is an assembly language
 syntax for specifying a program that is ultimately converted to AVM
 bytecode. These programs can be used to check the parameters of the
 transaction and approve the transaction as if by a signature. This use
@@ -16,7 +16,9 @@ few global values. In addition, _Smart Contracts_ have access to
 limited state that is global to the application and per-account local
 state for each account that has opted-in to the application. For both
 types of program, approval is signaled by finishing with the stack
-containing a single non-zero uint64 value.
+containing a single non-zero uint64 value, though `return` can be used
+to signal an early approval which approves based only upon the top
+stack value being a non-zero uint64 value.
 
 ## The Stack
 
@@ -34,8 +36,8 @@ exceeded or if a byte-array element exceed 4096 bytes, the program fails.
 
 In addition to the stack there are 256 positions of scratch
 space. Like stack values, scratch locations may be uint64s or
-byte-arrays. Scratch locations are intialized as uint64 zero. Scratch
-space is acccsed by the `load(s)` and `store(s)` opcodes which move
+byte-arrays. Scratch locations are initialized as uint64 zero. Scratch
+space is accessed by the `load(s)` and `store(s)` opcodes which move
 data from or to scratch space, respectively.
 
 ## Versions
@@ -82,19 +84,41 @@ even before the transaction has been included in a block. These Args
 are _not_ part of the transaction ID nor of the TxGroup hash. They
 also cannot be read from other programs in the group of transactions.
 
-A program can either authorize some delegated action on a normal private key signed or multisig account or be wholly in charge of a contract account.
-
-* If the account has signed the program (an ed25519 signature on "Program" concatenated with the program bytecode) then if the program returns true the transaction is authorized as if the account had signed it. This allows an account to hand out a signed program so that other users can carry out delegated actions which are approved by the program. Note that Smart Signature Args are _not_ signed.
-
-* If the SHA512_256 hash of the program (prefixed by "Program") is equal to the transaction Sender address then this is a contract account wholly controlled by the program. No other signature is necessary or possible. The only way to execute a 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 and the program cost must total no more than 20,000 (consensus parameter LogicSigMaxCost). Most opcodes have a cost of 1, but a few slow cryptographic operations are much higher. 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.
+A program can either authorize some delegated action on a normal
+signature-based or multisignature-based account or be wholly in charge
+of a contract account.
+
+* If the account has signed the program (by providing a valid ed25519
+  signature or valid multisignature for the authorizer address on the
+  string "Program" concatenated with the program bytecode) then: if the
+  program returns true the transaction is authorized as if the account
+  had signed it. This allows an account to hand out a signed program
+  so that other users can carry out delegated actions which are
+  approved by the program. Note that Smart Signature Args are _not_
+  signed.
+
+* If the SHA512_256 hash of the program (prefixed by "Program") is
+  equal to authorizer address of the transaction sender then this is a
+  contract account wholly controlled by the program. No other
+  signature is necessary or possible. The only way to execute a
+  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 and the program cost must total no more than 20,000
+(consensus parameter LogicSigMaxCost). Most opcodes have a cost of 1,
+but a few slow cryptographic operations have a much higher cost. 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.
 
 ## Execution Environment for Smart Contracts (Applications)
 
 Smart Contracts are executed in ApplicationCall transactions. Like
 Smart Signatures, contracts indicate success by leaving a single
-non-zero integer on the stack.  A failed smart contract call is not a
+non-zero integer on the stack.  A failed Smart Contract call is not a
 valid transaction, thus not written to the blockchain. Nodes maintain
 a list of transactions that would succeed, given the current state of
 the blockchain, called the transaction pool. Nodes draw from the pool
@@ -113,34 +137,54 @@ blockchain.
 ### Resource availability
 
 Smart contracts have limits on their execution budget (700, consensus
-paramter MaxAppProgramCost), and the amount of blockchain state they
+parameter MaxAppProgramCost), and the amount of blockchain state they
 may examine.  Opcodes may only access blockchain resources such as
 Accounts, Assets, and contract state if the given resource is
-_available_. 
+_available_.
 
  * A resource in the "foreign array" fields of the ApplicationCall
    transaction (`txn.Accounts`, `txn.ForeignAssets`, and
    `txn.ForeignApplications`) is _available_.
 
- * The `global CurrentApplicationID` and `txn.Sender` are _available_.
+ * The `txn.Sender`, `global CurrentApplicationID`, and `global
+   CurrentApplicationAddress` are _available_.
 
  * Prior to v4, all assets were considered _available_ to the
-   `asset_holding_get` opcode.
+   `asset_holding_get` opcode, and all applications were _available_
+   to the `app_local_get_ex` opcode.
 
  * Since v6, any asset or contract that was created earlier in the
-   same transaction group is _available_. In addition, any account
-   that is the contract account of a contract that was created earlier
-   in the group is _available_.
+   same transaction group (whether by a top-level or inner
+   transaction) is _available_. In addition, any account that is the
+   associated account of a contract that was created earlier in the
+   group is _available_.
 
 ## Constants
 
-Constants are loaded into storage separate from the stack and scratch space. They can then be pushed onto the stack by referring to the type and index. This makes for efficient re-use of byte constants used for account addresses, etc. Constants that are not reused can be pushed with `pushint` or `pushbytes`.
+Constants can be pushed onto the stack in two different ways:
+
+1. Constants can be pushed directly with `pushint` or
+   `pushbytes`. This method is more efficient for constants that are
+   only used once.
 
-The assembler will hide most of this, allowing simple use of `int 1234` and `byte 0xcafed00d`. These constants will automatically get assembled into int and byte pages of constants, de-duplicated, and operations to load them from constant storage space inserted.
+2. Constants can be loaded into storage separate from the stack and
+   scratch space, using two opcodes `intcblock` and
+   `bytecblock`. Then, constants from this storage can be pushed
+   pushed onto the stack by referring to the type and index using
+   `intc`, `intc_[0123]`, `bytec`, and `bytec_[0123]`. This method is
+   more efficient for constants that are used multiple times.
 
-Constants are prepared by two opcodes, `intcblock` and `bytecblock`. Both of these use [proto-buf style variable length unsigned int](https://developers.google.com/protocol-buffers/docs/encoding#varint), reproduced [here](#varuint). The `intcblock` opcode is followed by a varuint specifying the length of the array and then that number of varuint. The `bytecblock` opcode is followed by a varuint array length then that number of pairs of (varuint, bytes) length prefixed byte strings.
+The assembler will hide most of this, allowing simple use of `int 1234`
+and `byte 0xcafed00d`. Constants introduced via `int` and `byte` will
+be assembled into appropriate uses of `pushint|pushbytes` and
+`{int|byte}c, {int|byte}c_[0123]` to minimize program size.
 
-Constants are pushed onto the stack by `intc`, `intc_[0123]`, `pushint`, `bytec`, `bytec_[0123]`, and `pushbytes`. The assembler will handle converting `int N` or `byte N` into the appropriate form of the instruction needed.
+The opcodes intcblock and bytecblock use [proto-buf style variable length unsigned int](https://developers.google.com/protocol-buffers/docs/encoding#varint),
+reproduced [here](#varuint). The `intcblock` opcode is followed by a
+varuint specifying the number of integer constants and then that
+number of varuints. The `bytecblock` opcode is followed by a varuint
+specifying the number of byte constants, and then that number of pairs
+of (varuint, bytes) length prefixed byte strings.
 
 ### Named Integer Constants
 
@@ -405,10 +449,10 @@ Some of these have immediate data in the byte or bytes after the opcode.
 | 55 | LocalNumByteSlice | uint64 | v3  | Number of local state byteslices in ApplicationCall |
 | 56 | ExtraProgramPages | uint64 | v4  | Number of additional pages for each of the application's approval and clear state programs. An ExtraProgramPages of 1 means 2048 more total bytes, or 1024 for each program. |
 | 57 | Nonparticipation | uint64 | v5  | Marks an account nonparticipating for rewards |
-| 58 | Logs | []byte | v5  | Log messages emitted by an application call (`itxn` only until v6). Application mode only |
-| 59 | NumLogs | uint64 | v5  | Number of Logs (`itxn` only until v6). Application mode only |
-| 60 | CreatedAssetID | uint64 | v5  | Asset ID allocated by the creation of an ASA (`itxn` only until v6). Application mode only |
-| 61 | CreatedApplicationID | uint64 | v5  | ApplicationID allocated by the creation of an application (`itxn` only until v6). Application mode only |
+| 58 | Logs | []byte | v5  | Log messages emitted by an application call (only with `itxn` in v5). Application mode only |
+| 59 | NumLogs | uint64 | v5  | Number of Logs (only with `itxn` in v5). Application mode only |
+| 60 | CreatedAssetID | uint64 | v5  | Asset ID allocated by the creation of an ASA (only with `itxn` in v5). Application mode only |
+| 61 | CreatedApplicationID | uint64 | v5  | ApplicationID allocated by the creation of an application (only with `itxn` in v5). Application mode only |
 
 
 Additional details in the [opcodes document](TEAL_opcodes.md#txn) on the `txn` op.
@@ -507,7 +551,7 @@ Account fields used in the `acct_params_get` opcode.
 | `uncover n` | remove the value at depth N in the stack and shift above items down so the Nth deep value is on top of the stack. Fails if stack depth <= N. |
 | `swap` | swaps A and B on stack |
 | `select` | selects one of two values based on top-of-stack: B if C != 0, else A |
-| `assert` | immediately fail unless X is a non-zero number |
+| `assert` | immediately fail unless A is a non-zero number |
 | `callsub target` | branch unconditionally to TARGET, saving the next instruction on the call stack |
 | `retsub` | pop the top instruction from the call stack and branch to it |
 
@@ -569,7 +613,7 @@ the the array, rather than setting the entire array at once.
 
 `itxn_field` fails immediately for unsupported fields, unsupported
 transaction types, or improperly typed values for a particular
-field. `itxn_field` makes aceptance decisions entirely from the field
+field. `itxn_field` makes acceptance decisions entirely from the field
 and value provided, never considering previously set fields. Illegal
 interactions between fields, such as setting fields that belong to two
 different transaction types, are rejected by `itxn_submit`.
@@ -661,7 +705,7 @@ This requirement is enforced as follows:
 * Compute the largest version number across all the transactions in a group (of size 1 or more), call it `maxVerNo`. If any transaction in this group has a program with a version smaller than `maxVerNo`, then that TEAL program will fail.
 
 In addition, applications must be version 6 or greater to be eligible
-for calling in an inner transaction.
+for being called in an inner transaction.
 
 ## Varuint