Commit 638c98d9 authored by Julien Hamilton's avatar Julien Hamilton

New TZIP repo structure

parent 21d31e49
---
tzip: 1
title: TZIP-0001 (TZIP Purpose and Guidelines) FAQ
status: WIP
type: Meta
author: John Burnham, Jacob Arluck
advocate: John Burnham, Jacob Arluck
created: 2019-04-12
---
## What is a TZIP?
Response copied from [TZIP-0001](/Proposals/TZIP-0001/TZIP-0001.md#what-is-a-tzip):
An TZIP is a design document providing information to the Tezos community,
describing a feature for Tezos or its processes or environment, and supporting
the formal protocol governance process.
## Why do we need this?
Let's start from the assumption that Tezos needs some sort of asset standards
comparable to the role "ERC" plays on Ethereum, which is something a lot of
people have asked for. If we accept this premise, then there are two options:
1. Informal standards with no standards process
2. Formal standards with a a standards process
There are examples of both kinds of standards in the blockchain community, but
in our opinion informal standards are much more common. In general, informal
standards make decision-making processes opaque and result in poorer quality
standards documents. High-quality standards don't just appear overnight; they
are public goods that have to be carefully and thoughtfully *built*. We think
that a formal standards process is the best way to do this.
## Wouldn't it be simpler to just write the application standards first?
We are developing the application standards
[A1: Michelson Contract Interfaces and Conventions](/Proposals/TZIP-0004/A1.md),
[FA1: Unsafe Ledger](/Proposals/TZIP-0005/FA1.md) at the same time as the Meta-level TZIPs.
This is a lot more work, but we think it's a fairer and more fruitful
alternative to just unilaterally promulgating our own standards.
We do genuinely need the application standards we're working on, but already
we've found that we've held our work to higher level of quality by thinking of
them in the context of a larger standards process.
## What's to prevent TZIP from becoming a centralized authority like EIP?
EIP has power in Ethereum because it acts as [Schelling
point](https://en.wikipedia.org/wiki/Focal_point_(game_theory)) in their system
of hard fork governance. This is reinforced by the fact that the EIP editors
are substantially the most influential or notable members of the Ethereum core
developer community.
Tezos has a different, and we believe more game-theoretically optimal, Schelling
point in the protocol amendment process by the Tezos Quorum. We've proposed this
design of the TZIP process to support the Quorum by making TZIP an effective
process for producing good quality documentation that is completely non-binding
upon anyone. In a very real sense, we've tried to imagine what EIP would look
like if it only had an "Informational" standards track.
## Who are the editors going to be?
We don't know! We've left this question open because it needs to be answered by
the Tezos community as a whole. We hope we can all collectively design a fair
and legtimate mechanism for electing (and removing) TZIP editors. One possible
way to do this might be to use a Quorum vote to select the editors. Another way
might be to have an in-person election at some future Tezos conference.
Whatever the mechanism, we think it should be democratic and transparent:
If the composition of TZIP editors ends up looking analogous the composition of
EIP editors, we will consider this entire proposal to have been a failure.
This diff is collapsed.
This diff is collapsed.
......@@ -6,44 +6,42 @@ TZIP (pronounce "tee-zip") stands for Tezos Improvement Proposal, which are docu
A TZIP is a design document providing information to the Tezos community, describing a feature for Tezos or its processes or environment, and supporting the formal protocol governance process. A TZIP should contain a concise technical specification and rationale which unambiguously articulates what the proposal is, how it may be implemented, and why the proposal is an improvement.
A TZIP should additionally contain an FAQ, which which documents, compares and answers alternative options, opinions and objections.
A TZIP should additionally contain an FAQ which documents, compares, and answers alternative options, opinions, and objections.
## Current TZIPs
| TZIP | Title | Creation Date | Status |
| :---------: | :------------------------------------------------- | :-----------: | :----------------------- |
| [TZIP-0001] | TZIP Purpose and Guidelines | 04/10/2019 | Improvements in progress |
| [TZIP-0002] | TZIP Index | 04/10/2019 | Proposal |
| [TZIP-0003] | TZIP Code of Conduct | 04/10/2019 | Proposal |
| [TZIP-0004] | A1 - Michelson Contract Interfaces and Conventions | 04/11/2019 | Proposal |
| [TZIP-0005] | FA1 - Abstract Ledger | 04/12/2019 | Proposal |
| [TZIP-0006] | A1.1 - Balanced Trees for nested or and pair types | 05/04/2019 | Proposal |
| [TZIP-0007] | FA1.2 - Approvable Ledger | 06/20/2019 | Proposal |
| [TZIP-0008] | Payment Request Format | 06/25/2019 | Proposal |
| [TZIP-0009] | Info Field for Payment Requests | 06/25/2019 | Proposal |
| [TZIP-0010] | LA1 - Wallet Interaction Standard | 09/17/2019 | Work In Progress |
| [TZIP-0011] | Contract Specification Schema | - | Work In Progress |
| [TZIP-0012] | FA2 - Multi-Asset Contract (MAC) | - | Work In Progress |
## Contribute
If you want to contribute a proposal, please review the TZIP structure in [TZIP-0001](Proposals/TZIP-0001/TZIP-0001.md). You may find TZIP templates in the [Templates] folder helpful.
Create a new subfolder in [Proposals] named for your TZIP, and include the proposal, faq, and any assets (e.g. contracts) in that subfolder. Note that TZIPs and faqs should be written in [Markdown](https://docs.gitlab.com/ee/user/markdown.html) format.
Once you have written your proposal, please open a merge request with your proposal for review. Please remember to update the `Current TZIPs` table in the README in your MR.
[tzip-0001]: Proposals/TZIP-0001
[tzip-0002]: Proposals/TZIP-0002
[tzip-0003]: Proposals/TZIP-0003
[tzip-0004]: Proposals/TZIP-0004
[tzip-0005]: Proposals/TZIP-0005
[tzip-0006]: Proposals/TZIP-0006
[tzip-0007]: Proposals/TZIP-0007
[tzip-0008]: Proposals/TZIP-0008
[tzip-0009]: Proposals/TZIP-0009
[tzip-0010]: Proposals/TZIP-0010
[tzip-0011]: Proposals/TZIP-0011
[tzip-0012]: Proposals/TZIP-0012
[templates]: Templates
[proposals]: Proposals
| TZIP | Title | Creation Date | Status |
| :-------: | :--------------------------------------------------------- | :-----------: | :----------------- |
| [TZIP-1] | TZIP Purpose and Guidelines | 04/10/2019 | Submitted |
| [TZIP-2] | TZIP Types and Naming | 04/10/2019 | Submitted |
| [TZIP-3] | TZIP Code of Conduct | 04/10/2019 | Submitted |
| [TZIP-4] | **A1** - Michelson Contract Interfaces and Conventions | 04/11/2019 | Submitted |
| [TZIP-5] | **FA1** - Abstract Ledger | 04/12/2019 | Submitted |
| [TZIP-6] | **A1.1** - Balanced Trees for nested or and pair types | 05/04/2019 | Submitted |
| [TZIP-7] | **FA1.2** - Approvable Ledger | 06/20/2019 | Submitted |
| [TZIP-8] | Payment Request Format | 06/25/2019 | Draft |
| [TZIP-9] | Info Field for Payment Requests | 06/25/2019 | Draft |
| [TZIP-10] | **LA1** - Wallet Interaction Standard | 09/17/2019 | Work In Progress |
| [TZIP-11] | Contract Specification Schema | - | Draft |
| [TZIP-12] | **FA2** - Multi-Asset Contract (MAC) | - | Draft |
## How to Contribute
If you want to contribute a proposal, please review the TZIP structure in [TZIP-1](/proposals/tzip-1/tzip-1.md). You may find TZIP templates in the [templates](/templates) folder helpful.
Create a new subfolder in [proposals](/proposals) named for your TZIP, and include the proposal, FAQ, and any assets (e.g. contracts) in that subfolder. Note that TZIPs and FAQs should be written in [Markdown](https://docs.gitlab.com/ee/user/markdown.html) format.
Once you have written your proposal, please open a merge request with your proposal for review. Please remember to update the *Current TZIPs* table (see above) in your merge request.
[TZIP-1]: proposals/tzip-1
[TZIP-2]: proposals/tzip-2
[TZIP-3]: proposals/tzip-3
[TZIP-4]: proposals/tzip-4
[TZIP-5]: proposals/tzip-5
[TZIP-6]: proposals/tzip-6
[TZIP-7]: proposals/tzip-7
[TZIP-8]: proposals/tzip-8
[TZIP-9]: proposals/tzip-9
[TZIP-10]: proposals/tzip-10
[TZIP-11]: proposals/tzip-11
[TZIP-12]: proposals/tzip-12
---
Header has to be copied from the created TZIP.
tzip: <TZIP index code> (this is determined by the editor)
title: <TZIP title>
author: <a list of the author's or authors' name(s) and/or username(s), or
name(s) and email(s). [More Details](/Proposals/TZIP-0001/TZIP-0001.md#author-header)>
advocate *: <a list of the author's or authors' name(s) and/or username(s), or
name(s) and email(s). [More Details](/Proposals/TZIP-0001/TZIP-0001.md#author-header)>
gratuity *: <a Tezos address controlled by an author capable of receiving
gratuities from grateful Tezoi>
discussions-to *: <a url pointing to the official discussion thread>
status: <WIP | Draft | Last Call | Final | Active | Pending | Protocol | Rejected | Superseded>
review-period-end *: <date review period ends>
type: <Defined in [TZIP-0002](/Proposals/TZIP-0002/TZIP-0002.md#tzip-index-types)>
created: <date created on>
updated *: <comma separated list of dates>
requires *: <TZIP indices>
replaces *: <TZIP indices>
superseded-by *: <TZIP indices>
---
## Question
Answer to the question as descriptive as possible to paint a clear picture for the reader.
---
tzip: 1
title: TZIP-1 (TZIP Purpose and Guidelines) FAQ
status: Submitted
type: Meta
author: John Burnham, Jacob Arluck (@governancy), Julien Hamilton (@julien.hamilton)
created: 2019-04-12
---
## What is a TZIP?
A TZIP is a design document providing information to the Tezos community, describing a feature for Tezos, its processes, or environment, and supporting the formal protocol governance process.
## Why do we need TZIPs?
Let's start from the assumption that Tezos needs some sort of asset standards comparable to the role "ERC" plays on Ethereum, which is something a lot of people have asked for. If we accept this premise, then there are two options:
1. Informal standards with no standards process
2. Formal standards with a standards process
There are examples of both kinds of standards in the blockchain community, but in our opinion informal standards are much more common. In general, informal standards make decision-making processes opaque and result in poorer quality standards documents. High-quality standards don't just appear overnight; they are public goods that have to be carefully and thoughtfully *built*. We think that a formal standards process is the best way to do this.
This diff is collapsed.
---
tzip: 10 (LA1)
title: Wallet Interaction Standard
tzip: 10
title: LA1 - Wallet Interaction Standard
author: Alessandro De Carli <[email protected]>, Mike Godenzi <[email protected]>, Andreas Gassmann <[email protected]>, Pascal Brun <@pascuin>
discussions-to: https://forum.tezosagora.org/t/wallet-interaction-standard/1399
status: WIP
review-period-end: <date review period ends>
status: Work In Progress
type: LA
created: 2019-09-17
updated: 2019-10-09, 2019-10-12, 2019-10-24, 2019-12-09
---
## What has been discussed in the first workshop - 2019-09-29?
......@@ -138,5 +136,5 @@ The unedited meeting notes from the call on October 24th which will be reviewed
### Next steps
- share dockerhub link & documentation
- iterate over feedback, include in pull request
- iterate over feedback, include in merge request
-- include glossary and scenarios
---
tzip: 10 (LA1)
tzip: 10
title: Wallet Interaction Standard
author: Alessandro De Carli <[email protected]>, Mike Godenzi <[email protected]>, Andreas Gassmann <[email protected]>, Pascal Brun <@pascuin>
discussions-to: https://forum.tezosagora.org/t/wallet-interaction-standard/1399
status: WIP
review-period-end: <date review period ends>
status: Work In Progress
type: LA
created: 2019-09-17
updated: 2019-10-09, 2019-10-12, 2019-10-24
---
## Simple Summary
## Summary
Communication between wallets and decentralised applications.
......
---
tzip: 2
title: TZIP Types and Naming
status: Submitted
type: Meta
author: John Burnham, Julien Hamilton (@julien.hamilton)
created: 2019-04-10
---
## Summary
This document lists the different types a TZIP can be, with their descriptions. In addition, we explain how to use types to name some TZIPs (e.g. FA1, FA1.2, LA1).
## List of TZIP Types
| Type Prefix | Topic | Description |
|-------------|------------------------|----------------------------|
| | Meta | This type describes a process surrounding Tezos or proposes a change to (or an event in) a process. Examples include procedures, guidelines, changes to the TZIP process itself, or proposals for new social institutions and spaces. The present document is a Meta TZIP. |
| `A` | Application | Applications built on top of Tezos, particularly smart contract or higher layer applications. |
| `LA` | Layer-n Application | Higher-layer applications which use the Tezos chain e.g. for settlement or communication. |
| `FA` | Financial Application | Applications involving the management, allocation or transfer of instruments which mediate economic value, such as assets or liabilities. |
| `I` | Interface | Improvements around client API/RPC specifications and standards. |
| `L` | Language | Improvements to smart contract, formal proof, or implementation languages. Examples are specifications for [Michelson](https://tezos.gitlab.io/whitedoc/michelson.html), [LIGO](https://ligolang.org/), [SmartPy](https://smartpy.io/), [Morley](http://hackage.haskell.org/package/morley), [Fi](https://learn.fi-code.com/), or best practices for Tezos projects using OCaml, Haskell, Rust, JavaScript, Coq, Agda, etc. |
| `N` | Networking | Improvements to the peer-to-peer layer. |
| `X` | Cryptography | Improvements to cryptographic primitives. |
| `Z` | Informational | Discusses a Tezos design issue, or provides general guidelines or information to the Tezos community. |
Additional types of TZIP may be proposed, and existing TZIP types may also be deprecated by future Meta TZIPs. All the updates will be maintained in this TZIP ([TZIP-2](/proposals/tzip-2/tzip-2.md)).
## Naming
Some TZIPs, like smart contract specifications, have a distinct *name* that is used to identify them. This is in addition to their TZIP number.
We define the TZIP name as two components:
1. An alphabetic Type prefix (e.g. FA or P) which signifies the standard's topic or domain of relevance. The valid TZIP types are available in the *List of Types* discussed above.
2. A serial number represented as a list of dot separated numbers (e.g. 1.2.3 or 15), which signifies whether the standard is an extension or specialization of another more general standard. For example 2.34 would be the extension number 34 of the root standard number 2.
## Copyright
Copyright and related rights waived via
[CC0](https://creativecommons.org/publicdomain/zero/1.0/).
---
tzip: 3
title: TZIP Code of Conduct
status: Active
status: Submitted
type: Meta
author: John Burnham
advocate: John Burnham
author: John Burnham, Julien Hamilton (@julien.hamilton)
created: 2019-04-10
---
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity and
expression, level of experience, education, socio-economic status, nationality,
personal appearance, race, religion, or sexual identity and orientation.
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment
include:
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
......@@ -30,57 +23,31 @@ include:
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies within all project spaces, and it also applies when
an individual is representing the project or its community in public spaces.
Examples of representing a project or community include using an official
project e-mail address, posting via an official social media account, or acting
as an appointed representative at an online or offline event. Representation of
a project may be further defined and clarified by project maintainers.
This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at [email protected] All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 1.4, available at
https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html.
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see
https://www.contributor-covenant.org/faq
For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq.
---
tzip: 4 (A1)
title: Michelson Contract Interfaces and Conventions
status: WIP
tzip: 4
title: A1 - Michelson Contract Interfaces and Conventions
status: Submitted
type: Application
author: John Burnham, Konstantin Ivanov
advocate: John Burnham, Konstantin Ivanov
author: John Burnham, Konstantin Ivanov <[email protected]>
advocate: John Burnham, Konstantin Ivanov <[email protected]>
created: 2019-04-11
---
......@@ -73,7 +73,7 @@ with field annotations, and all top-level union type arguments are unannotated.
Nevertheless, it is advisable that specific implementations adhere to a
consistent tree-struct convention, examples of which can be seen in various
extensions of this standard (such as [`TZIP-0006 (A1.1)`](/Proposals/TZIP-0006/A1.1.md)).
extensions of this standard (such as [`TZIP-6`](/proposals/tzip-6/tzip-6.md)).
### Example
......@@ -186,7 +186,7 @@ indentation and whitespacing rules.
This standard defines only tuples and unions of size two.
Introduced syntax sugar becomes especially useful in extensions of the
standard where this syntax is generalized
(see [`TZIP-0006 (A1.1)`](/Proposals/TZIP-0006/A1.1.md) for example).
(see [`TZIP-6`](/proposals/tzip-6/tzip-6.md) for example).
# CASE macro
......
---
tzip: 5 (FA1)
author: John Burnham, Konstantin Ivanov
tzip: 5
author: John Burnham, Konstantin Ivanov <[email protected]>
created: 2019-07-17
---
## Summary
This document describes an implementation of [FA1 interface](/Proposals/TZIP-0005/FA1.md).
This document describes an implementation of the [TZIP-5](/proposals/tzip-5/tzip-5.md) interface.
Michelson code of resulting contract can be found [here](/Proposals/TZIP-0005/AbstractLedger.tz).
Michelson code of resulting contract can be found [here](/proposals/tzip-5/AbstractLedger.tz).
## Unsafe Ledger Parameter
......@@ -20,7 +20,7 @@ parameter
);
```
See also [syntax explanation](/Proposals/TZIP-0004/A1.md#pairs-and-ors-syntax-sugar) and [Michelson Contract Interfaces and Conventions Document](/Proposals/TZIP-0004/A1.md#view-entrypoints).
See also [syntax explanation](/proposals/tzip-4/tzip-4.md#pairs-and-ors-syntax-sugar) and [Michelson Contract Interfaces and Conventions Document](/proposals/tzip-4/tzip-4.md#view-entrypoints).
## Unsafe Ledger Storage
......@@ -40,7 +40,7 @@ the sum of balances must be reflected by a corresponding changing the `nat
This contract has been written in Lorentz eDSL - a [language over Haskell](https://hackage.haskell.org/package/morley-0.3.0.1) which provides some extensions to basic Michelson and generally improves development experience.
The contract code can be found
[here](https://gitlab.com/morley-framework/morley/blob/ce28076a79b93d48aa7745271e6a1395b8b9e50d/lorentz-contracts/src/Lorentz/Contracts/AbstractLedger.hs), resulting Michelson code resides [here](/Proposals/TZIP-0005/AbstractLedger.tz).
[here](https://gitlab.com/morley-framework/morley/blob/ce28076a79b93d48aa7745271e6a1395b8b9e50d/lorentz-contracts/src/Lorentz/Contracts/AbstractLedger.hs), resulting Michelson code resides [here](/proposals/tzip-5/AbstractLedger.tz).
### Compiling Lorentz contract
......
---
tzip: 5 (FA1)
title: Abstract Ledger
status: WIP
tzip: 5
title: FA1 - Abstract Ledger
status: Submitted
type: Financial Application
author: John Burnham, Konstantin Ivanov, Kirill Kuvshinov
advocate: John Burnham, Konstantin Ivanov, Kirill Kuvshinov
author: John Burnham, Konstantin Ivanov <[email protected]>, Kirill Kuvshinov (@kkirka)
advocate: John Burnham, Konstantin Ivanov <[email protected]>, Kirill Kuvshinov (@kkirka)
created: 2019-04-12
---
......@@ -39,7 +39,7 @@ For FA1, parameter should contain the following leaves:
3. `view (address :owner) nat %getBalance`
2. `view unit nat %getTotalSupply`
See also [syntax explanation](/Proposals/TZIP-0004/A1.md#pairs-and-ors-syntax-sugar) and [Michelson Contract Interfaces and Conventions Document](/Proposals/TZIP-0004/A1.md#view-entrypoints).
See also [syntax explanation](/proposals/tzip-4/tzip-4.md#pairs-and-ors-syntax-sugar) and [Michelson Contract Interfaces and Conventions Document](/proposals/tzip-4/tzip-4.md#view-entrypoints).
## Errors
......
---
tzip: 6 (A1.1)
title: Balanced Trees for nested or and pair types
tzip: 6
title: A1.1 - Balanced Trees for nested or and pair types
status: Submitted
type: Application
author: John Burnham, Konstantin Ivanov
advocate: John Burnham, Konstantin Ivanov
author: John Burnham, Konstantin Ivanov <[email protected]>
advocate: John Burnham, Konstantin Ivanov <[email protected]>
created: 2019-05-04
---
## Summary
This standard extends `TZIP-0004 (A1)` by defining a right-hand balance tree structure
This standard extends `TZIP-4 (A1)` by defining a right-hand balance tree structure
for `or` and `pair` types. Structure of comb defined in
[TZIP-0004 (A1)](/Proposals/TZIP-0004/A1.md#entrypoints) is the most obvious one, but the worst-case
[TZIP-4](/proposals/tzip-4/tzip-4.md#entrypoints) is the most obvious one, but the worst-case
performance of operations on it scales linearly with number of elements
in the comb which is suboptimal. Whereas tree structure allows reaching better
average performance of access and update operations.
......@@ -58,7 +59,7 @@ If we insert a new node `f` into the above tree:
## ADT Syntax sugar
The [`Pair`s and `Or`s syntax sugar](/Proposals/TZIP-0004/A1.md#pairs-and-ors-syntax-sugar) is
The [`Pair`s and `Or`s syntax sugar](/proposals/tzip-4/tzip-4.md#pairs-and-ors-syntax-sugar) is
extended to work for tuples and unions of arbitrary size:
```
......
---
tzip: FA1.2
author: Konstantin Ivanov, Ivan Gromakovskii
tzip: 7
author: Konstantin Ivanov <[email protected]>, Ivan Gromakovskii (@gromak)
created: 2019-06-24
---
## Summary
This document describes a smart contract that implements [FA1.2 interface](/Proposals/TZIP-0007/FA1.2.md).
This document describes a smart contract that implements [TZIP-7](/proposals/tzip-7/tzip-7.md) inteface.
The contract also maintains an entity called _administrator_ which has an exclusive right to perform management operations like `Mint` and `Pause`.
The contract compiled to Michelson is provided in [ManagedLedger.tz](/Proposals/TZIP-0007/ManagedLedger.tz).
The contract compiled to Michelson is provided in [ManagedLedger.tz](/proposals/tzip-7/ManagedLedger.tz).
## Managed Ledger interface
`ManagedLedger.md` has entrypoints specified in FA1.2 along with additional entrypoints which make the ledger _managed_:
`ManagedLedger.md` has entrypoints specified in TZIP-7 along with additional entrypoints which make the ledger _managed_:
* `bool %setPause`
* `address %setAdministrator`
* `(view () address) %getAdministrator`
......@@ -21,8 +21,8 @@ The contract compiled to Michelson is provided in [ManagedLedger.tz](/Proposals/
* `(address :from, nat :value) %burn`
See also:
* [Syntax sugar explanation](/Proposals/TZIP-0004/A1.md#pairs-and-ors-syntax-sugar).
* [Explanation of `view`](/Proposals/TZIP-0004/A1.md#view-entrypoints).
* [Syntax sugar explanation](/proposals/tzip-4/tzip-4.md#pairs-and-ors-syntax-sugar).
* [Explanation of `view`](/proposals/tzip-4/tzip-4.md#view-entrypoints).
## Deployment
......@@ -33,7 +33,7 @@ Here `MANAGER_ADDR` is the address of the manager, `False` means that operations
## Errors
The contract follows exactly the same format for errors as described in
[FA1](/Proposals/TZIP-0005/FA1.md#errors).
[TZIP-5](/proposals/tzip-5/tzip-5.md#errors).
For example, if an entrypoint is stated to fail with `SenderIsNotAdmin` error,
then a client should expect contract to fail with `("SenderIsNotAdmin", Unit)` pair.
......@@ -41,7 +41,7 @@ The second element of this pair may vary depending on the kind of error.
## Entrypoints
Along with entrypoints described in FA1.2, the contract exposes basic management operations.
Along with entrypoints described in TZIP-7, the contract exposes basic management operations.
### setPause
......
---
tzip: 7 (FA1.2)
author: Konstantin Ivanov, Ivan Gromakovskii
tzip: 7
status: Submitted
author: Konstantin Ivanov <[email protected]>, Ivan Gromakovskii (@gromak)
created: 2019-04-12
---
......@@ -8,7 +9,7 @@ created: 2019-04-12
Parameter is the only easy way for a caller to pass some data to a contract.
We do not know in advance which data an arbitrary contract can use.
If we specify a concrete parameter type which is a tree of `or` types where each leaf corresponds to some method from FA1.2, it means that contract can not have any other input data, hence it can not have methods other than those listed in FA1.2.
If we specify a concrete parameter type which is a tree of `or` types where each leaf corresponds to some method from TZIP-7, it means that contract can not have any other input data, hence it can not have methods other than those listed in TZIP-7.
While we can use a proxy contract to adapt a more general parameter type to a concrete one, such an approach has the following disadvantages:
1. It is harder to implement and use, hence more error-prone.
In particular, special care should be taken to make sure that proper `SENDER` value is propagated by the proxy contract.
......@@ -23,11 +24,11 @@ Since the caller of a contract can specify an entrypoint she wants to invoke, we
## Why do not you require concrete shape of parameter tree?
Michelson documentation defines "a contract with entrypoints" as "a contract that takes a disjunctive type (a nesting of `or` types) as the root of its input parameter, decorated with constructor annotations".
We could require this disjunctive type to have a particular shape, e. g. to be a right- or left-hand comb or a balanced tree with all FA1.2 methods located in some specific place.
We could require this disjunctive type to have a particular shape, e. g. to be a right- or left-hand comb or a balanced tree with all TZIP-7 methods located in some specific place.
However, such a requirement would have a few drawbacks:
1. It complicates composability of contract interfaces.
If our interface requires certain methods to be in a particular place and another interface has a similar requirement, these two interfaces most likely will be incompatible.
If we only require all FA1.2 methods to have a common node in the tree of `or`s, we'll encounter an incompatibility issue if another interface has methods with the same names and a similar requirement.
If we only require all TZIP-7 methods to have a common node in the tree of `or`s, we'll encounter an incompatibility issue if another interface has methods with the same names and a similar requirement.
2. It imposes unnecessary restriction on contract developers.
We consider this restriction unnecessary, because the entrypoints feature allows one to call contract's method without knowing anything about its parameter shape.
Without this restriction high level languages can pick representation of nested `or` types which is more suitable for them.
......
---
tzip: 7 (FA1.2)
title: Approvable Ledger
status: WIP
tzip: 7
title: FA1.2 - Approvable Ledger
status: Submitted
type: Financial Application
author: Konstantin Ivanov, Ivan Gromakovskii, Kirill Kuvshinov
advocate: Konstantin Ivanov, Ivan Gromakovskii, Kirill Kuvshinov
author: Konstantin Ivanov <[email protected]>, Ivan Gromakovskii (@gromak), Kirill Kuvshinov (@kkirka)
advocate: Konstantin Ivanov <[email protected]>, Ivan Gromakovskii (@gromak), Kirill Kuvshinov (@kkirka)
created: 2019-06-20
---
......@@ -27,8 +27,8 @@ A contract which implements approvable ledger must have the following entrypoint
This standard specifies additional authorization checks for `%transfer` entrypoint, as explicitly allowed by FA1.
See also:
* [Syntax sugar explanation](/Proposals/TZIP-0004/A1.md#pairs-and-ors-syntax-sugar).
* [Explanation of `view`](/Proposals/TZIP-0004/A1.md#view-entrypoints).
* [Syntax sugar explanation](/proposals/tzip-4/tzip-4.md#pairs-and-ors-syntax-sugar).
* [Explanation of `view`](/proposals/tzip-4/tzip-4.md#view-entrypoints).
## Errors
......
......@@ -2,12 +2,12 @@
tzip: 8
title: Payment Request Format
status: Draft
type: TRC
type: Interface
author: Martin Pospěch <[email protected]>
created: 2019-06-25
---
## Simple Summary
## Summary
URI scheme for Tezos payment requests.
......@@ -296,8 +296,7 @@ The payload format closely mirrors the format expected by Tezos RPC, so that it
To make the standard as simple to implement as possible, we have decided against a more abstract payload format.
### Misc. Information Field
The requests only include a subset of fields from the RPC format. To keep the standard simple, there are no extra fields such as a miscellaneous information field to describe a transaction. This could then be displayed by users' wallet, but wouldn't be sent anywhere. Extensions to the standard are possible, and a misc. information field is described by [TZIP-0009](/Proposals/TZIP-0009/TZIP-0009.md).
The requests only include a subset of fields from the RPC format. To keep the standard simple, there are no extra fields such as a miscellaneous information field to describe a transaction. This could then be displayed by users' wallet, but wouldn't be sent anywhere. Extensions to the standard are possible, and a misc. information field is described by [TZIP-9](/proposals/tzip-9/tzip-9.md).
## Implementation
JavaScript implementation is provided as an [npm package called tezos-uri](https://www.npmjs.com/package/tezos-uri). The code can be viewed [at gitlab](https://gitlab.com/smartcontractlabs/tezos-uri). This section contains advice and ideas related to implementing the standard and integrating it with wallets.
......@@ -313,7 +312,7 @@ Implementers are advised to verify during encoding and decoding that the content
When processing an array of requests, if one of the requests is malformed or contains invalid data, all of the requests should be treated as invalid.
#### Validate Michelson Data
Don't forget to validate Michelson data in `parameters` and `script` fields. The types are described in the [Tezos RPC index](https://tezos.gitlab.io/mainnet/api/rpc.html#post-block-id-helpers-forge-operations). The script can be legal according to the RPC specification and still fail during interpretation. This happens e.g. when an instruction has too few or too many arguments. Validating the Michelson data won't ensure that the script can be interpreted, but it will help catch mistakes sooner.
Don't forget to validate Michelson data in `parameters` and `script` fields. The types are described in the [Tezos RPC index](https://tezos.gitlab.io/api/rpc.html#post-block-id-helpers-forge-operations). The script can be legal according to the RPC specification and still fail during interpretation. This happens e.g. when an instruction has too few or too many arguments. Validating the Michelson data won't ensure that the script can be interpreted, but it will help catch mistakes sooner.
### Wallets
Integrating the standard in a wallet enables UX improvements, such as pre-filling transaction dialogs for users so that they just need to confirm. This is important for application UX, as users can't be expected to copy-paste parameters or gas and storage limits.
......
......@@ -2,18 +2,18 @@
tzip: 9
title: Info Field for Payment Requests
status: Draft
type: TRC
type: Informational
author: Martin Pospěch <[email protected]>
created: 2019-06-25
---
## Simple Summary
## Summary
Miscellaneous information extension for payment requests.
## Abstract
This document describes an extension to TZIP-0008 that adds an extra field to Tezos payment requests. The field can contain simple description of payment or their purpose. Wallets can dispay this in transaction history or when approving the payment.
This document describes an extension to [TZIP-8](/proposals/tzip-8/tzip-8.md) that adds an extra field to Tezos payment requests. The field can contain simple description of payment or their purpose. Wallets can dispay this in transaction history or when approving the payment.
## Motivation
......@@ -44,7 +44,7 @@ Information about the purpose of the payment will use a field called `info` with
## Appendix
### TZIP-0008 Implementations Supporting the Standard
### TZIP-8 Implementations Supporting the Standard
* TBA
### Wallets Implementing the Standard
......
---
Header has to be copied from the created TZIP.
tzip: TZIP number
title: TZIP title, with an optional name as a prefix (e.g. 'FA1 - Abstract Ledger')
author: Name(s) of author(s), ideally with their username(s) or email address(es)
advocate: Optional. Name(s) of advocate(s), ideally with their username(s) or email address(es)
gratuity: Optional. A Tezos address controlled by an author capable of receiving gratuities from grateful Tezos users
discussions-to: Optional. A url pointing to the official discussion thread
status: <Draft | Work In Progress | Withdrawn | Submitted | Superseded>
type: Defined in TZIP-2
created: Date created on, format yyyy-mm-dd
requires: Optional. Comma-separated TZIP numbers
replaces: Optional. Comma-separated TZIP numbers
superseded-by: Optional. Comma-separated TZIP numbers
---
## Question 1
Answer 1. Answer to the question as descriptive as possible to paint a clear picture for the reader.