From 151366ba5c5991ad1ed06fee7c82fcda0cee3535 Mon Sep 17 00:00:00 2001 From: Alessandro Coglio Date: Mon, 20 Sep 2021 11:04:51 -0700 Subject: [PATCH] [RFC] Add a new idea for handling transaction outputs. --- docs/rfc/012-record-transaction-model.md | 40 ++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/docs/rfc/012-record-transaction-model.md b/docs/rfc/012-record-transaction-model.md index 219de58673..d161c79f82 100644 --- a/docs/rfc/012-record-transaction-model.md +++ b/docs/rfc/012-record-transaction-model.md @@ -237,6 +237,46 @@ or perhaps they should be predicates, i.e. return `bool`, where `true` indicates a successful check (e.g. "yes, this private input yields this commitment when hashed") and `false` indicates a failed check. +Another possibility is to require entry point functions to return records as outputs. +More precisely, these may be smaller structures than records, +because some of the slots of the records may be only calculated outside of Leo, +but for the present discussion we will assume that Leo can calculate the whole records. +As mentioned earlier, a transaction may generate 0, 1, or 2 new records. +Correspondingly, we could require entry point functions to return results of one of the following types: +``` +@entrypoint function ...(...) -> () // when no new records are created +@entrypoint function ...(...) -> Record // when one new record is created +@entrypoint function ...(...) -> (Record, Record) // when two new records are created +// using an annotation for concreteness, but the point stands for the other options discussed +``` +In other words, an entry point function can be now seen as a mathematical function +``` +entrypoint : Record x Record x Inputs -> Record x Record +``` +where one or both output records are dummy if the function creates less than two new records. + +The above constrains each entry point to always return the same number of records. +Different entry point functions may return different numbers of records. +If we want the same entry point function +to return different numbers of records in different situations, +then it could make sense to have a more general circuit type for the output of a transaction, +which may contain 0, 1, or 2 records, and possibly other information as needed, +and require entry point functions to uniformly return values of that type: +``` +@entrypoint function ...(...) -> TransactionOutput // contains 0, 1, or 2 records +``` + +Earlier we discussed having a known and accessible circuit type for the `input` special variable. +This type could be called `TransactionInput`, which mirrors `TransactionOutput`. +In this case, it seems more natural to treat `input` not as a global variable, +but as a parameter of entry functions; +it could be the first parameter, required for every entry function that accesses the transaction input: +``` +@entrypoint function ...(input: TransactionInput, ...) -> TransactionOutput +``` +We could even drop `input` as a special keyword/expression altogether, +and allow any name (but suggest a convention) for the `TransactionInput` parameter of entry point functions. + ## Alternatives The 'Design' section above already outlines several alternatives to consider.