owned this note
owned this note
Published
Linked with GitHub
# Ticket Projects
Attendees: XF, Lin, Joel
## November 23
- [!6490](https://gitlab.com/tezos/tezos/-/merge_requests/6490) Originated -> Implicit.
- https://gitlab.com/tezos/tezos/-/merge_requests/6490#note_1181732520
- https://gitlab.com/tezos/tezos/-/merge_requests/6490#note_1181737307
- Look at the new tests (add comments, indent Michelson etc)
- [!6867](https://gitlab.com/tezos/tezos/-/merge_requests/6867)
- Ticket receipt for SCORU: (Lin to have a look)
- Originated to SCORU (need to scan SCORU type and value)
- SCORU to originated (execute outbox message emmits internal ops. To confirm behavior.)
## November 16
Attendees: XF, Lin, Joel
Needed for M:
- [x] [!6108](https://gitlab.com/tezos/tezos/-/merge_requests/6108) - Proto: Enable transferring tickets between implicit accounts
- [ ] [!6311](https://gitlab.com/tezos/tezos/-/merge_requests/6311) Remove entrypoint enc. Not strictly needed.
- [ ] [!6490](https://gitlab.com/tezos/tezos/-/merge_requests/6490) Originated -> Implicit.
- [ ] Ticket-receipts for implicit to implicit. MR pending.
- [ ] Ticket-receipts for originated to implicit. Should go in the current MR (6490)
- [ ] Ticket-receipts for originated to rollup (To be covered in a separate MR). Joel to take a look.
- [ ] Ticket-receipts for rollup to originated (To be covered in a separate MR). Joel to take a look.
- [ ] Blog post: Work in Progress.
- [ ] Blog post: Work in Progress.
- [ ] Docs in separate MR
- [ ] Name descrepency: Lower prio but Lin to have a look
## August 31
Attendees: Mehdi, XF, Joel
Zero-amount tickets:
- Add test for zero-amount in storage
- Consider client patch for detecting
Implicit account sending tickets
- How to deal with simple encoding for `Transfer_ticket`?
- Agreed not to use `receive_ticket` entrypoint for either case.
- Split features (implicit to implicit) and (originated to implicit)
## August 30
Attendees: XF, Joel
- Implicit to originated (already working but limited to single ticket). Nothing to do
- Implicit to implicit - needs to be enabled. One MR if possible. No need for entrypoint.
- Originated to implicit
Three options:
1. Entrypoint `receive_ticket`
2. special instruction
3. Just use `TRANSFER_TOKEN` and (`CONTRACT (ticket string)`)
## August 24
Attendees: Nicholas, XF, Joel, Lin
#### Implicit accounts ticket design
Discussed "Suggestion 1":
- Pros: more explicit. Easier to document.
- Clearer to deal with future extension
- Memo vs event
- Entrypoint + argument vs `--tickets`
Other topics:
- Decided to use one transaction operation
- Will use `receive_ticket` entrypoint (rather than special field `tickets`)
- Question: how do we specify the type for the ticket payload
- 1. Dynamic ticket route
- 2. Introduce a special `parameter_type/arg-type` field
- What do indexers prefer?
#### Zero-amount tickets
- Concern about existing 0 amount tickets
- MR mostly ready
#### Action points
- Xf: design doc for parameters-type field
- Xf: update design doc for tickets with parameters-type field
- Xf: propose parameters-type field in proto-channel
- Xf: propose to indexers
- Joel: review the MR for zero-amount tickets
#### Implicit ticket proposal
Contract call:
```
CONTRACT %receive_tickets (ticket string)
# Push tickets
TRANSFER_TOKENS
```
JSON call:
```
{
"amount": <tez amount in int>,
"entrypoint": "receive_ticket",
"destination": "tz1.../KT1...",
"parameters": "Pair tkrt (Pair "Hello" 42)"
"parameters_ty" : "ticket string"
}
```
tezos-client:
```
tezos-client transfer 1 from alice to bob \
--burn-cap 0.1 \
--arg 'Pair (Pair "0x...." (Pair "I am a ticket" 4)) 42'
--arg_type 'Pair (ticket string) nat'
```
## August 17
Attendees: Xf, Joel
### Zero-amount tickets
Dicussed:
- Push new commits as fixup
- What to do with `test_0_amount_tickets`?
- How to test cross protocol?
- Possibly see `protoco_migration.ml` in `tezt/tests`.
To test:
1. Old contracts with `TICKET` still works as before
2. New contracts with `TICKET` work with new semantics (returns option)
3. No new contracts can use the `TICKET_DEPRECATED` instruction
TODO:
- Document how "migration" works
### Implicit account ticket holders
- New implicit to implicit
- RPC for parse the type and check ticket content
-
## August 10
Attendees: Xf, Joel
## August 3
Attendees: Xf, Joel
Zero-amount tickets:
Implicit accounts to hold tickets:
## July 27
Attendees: Xf, Joel, Mehdi
Zero-amount tickets:
- New instruction (and deprecate the old one):
- Rename `TICKET` to `LEGACY_TICKET`
- New `TICKET` instruction that returns an option
- See !4670 !4589 for deprecating sapling instr
Implicit accounts to hold tickets
- Two steps (first pass type and ticket then dynamic ticket type)
- Xf to check with Thomas L
## July 25
Attendees: Xf, Joel
### Zero-amount-tickets
- For find zero-tickets on mainnet: [Migration code for ticket](https://gitlab.com/tezos/tezos/-/merge_requests/3826/diffs#5cfdabc50a6df7a536461c09f066a51a43329548)
- Pattern for splitting with zero-amount (used in tests)
- Operations:
1. `SPLIT_TICKET` - already returns `NONE`
2. `JOIN_TICKET` - same.
3. `TICKET` now would fail on `0`. Is this fine, or should we change the signature?
- Discuss on protocall
- Set up recurring meeting Monday 4pm CET
Next steps:
- Resolve `TICKET 0` exception question
- Xf to to change tests for tickets to pass
- Write scanner to check if there are zero-tickets on mainnet
1. For each contract: does storage have ticket type?
2. If so, check each ticket and report on zero-amounts
3. How many contract actually contain tickets?
## July 12
Attendees: Lin, Xf, Mehdi, Joel
### Implicit account to originated:
- `Transfer_ticket` already exists. Allows only one ticket
- Generalize by using regular transfer. Only addition is ticket-scanning and update balance
- Allows transfering multiple tickets
- Need to test all combinations of different tickets and payloads
- Should probably deprecate this `Transfer_ticket` instruction
### Originated to implicit
- Introduce another internal transfer.
- See [Transaction_to_implicit](https://gitlab.com/tezos/tezos/-/blob/master/src/proto_alpha/lib_protocol/script_typed_ir.mli#L1484)
- Similar to transfer-to-tx-rollup (but without l2 address)
- Add a case to typed-contract
- Handle new entrypoint in parse contract
- Limit to single ticket for now (Reconsider when we have extistential types for passing multiple tickets)
Conceptually:
```ocaml=
| Transaction_to_implicit_with_ticket : {
destination : Signature.Public_key_hash.t;
amount : Tez.tez;
parameters : 'a ticket;
parameters_ty : 'a ticket ty;
}
| Transaction_to_implicit : {
destination : Signature.Public_key_hash.t;
amount : Tez.tez;
}
```
### Implicit to implicit
- Use existing transfer
- Use same entrypoint as in originated-to-implicit case
### Implicit to tx/sc rollup
- Implicit to tx should be straight forward - check with Thomas Letan
- For SC only consider if there is demand
### Originated to originated
- Already supported
### Additional
- Consider providing an entrypoint for checking that address holds tickets
- Implicit account to create tickets?
### Next steps
- [ ] Lin, Xf to create a design doc an updat the Miltesone
- [ ] Tom Jack, Mehdi, Joel and others to provide feedback
- [ ] Set up a seperate meeting for "zero-amount tickets"
- [ ] Discuss with Thomas L about deprecating `Transfer_ticket` (and general feedback)