Add design proposal for generalized ownership #3216

aeyakovenko · 2019-03-11T05:25:37Z

Problem

Current implementations of ownership rely on account pubkeys, which cannot be composed across programs.

How these problems manifest in Ethereum. https://medium.com/@kelvinfichter/looking-at-ownership-in-the-evm-6e6914d341d

Summary of Changes

Propose a design for general ownership of countable things, with a mechanism to programatically transfer the ownership based on output from other programs.

CC #3266

book/src/generalized-ownership.md

garious

I can't give much feedback on this yet. Need more context on the problem being solved. If it's solving the problem that I think it's solving, I'm surprised not to see monoids mentioned in the proposed solution. Seems like this should be a debate between monoids and semigroups and how a program should expose that functionality to accounts that it is the owner of.

I'd think this proposal can take the form:

Runtime doesn't allow parallel access to "credits" on userdata, because it doesn't know what it means to be a credit on an otherwise opaque data type. To define a credit, we propose programs optionally implement a semigroup interface for accounts it owns. Going one step further, the runtime can also create and initialize these accounts if an identity operation is defined. When used in conjunction, the identity and semigroup operations form a monoid, opening the door for additional runtime optimizations such as the popular MapReduce.

book/src/generalized-ownership.md

garious · 2019-03-13T15:30:15Z

book/src/generalized-ownership.md

+This design describes generalized ownership of countable items on the Solana
+blockchain. The goal of this design is to propose a single general-purpose
+program whose state can be used across many different programs to implement
+ownership, transfer and programmatic assignment. 


programmatic?

Assignment based on the output of a program? What should you call it?

garious · 2019-03-13T15:30:45Z

book/src/generalized-ownership.md

+program whose state can be used across many different programs to implement
+ownership, transfer and programmatic assignment. 
+
+Many programs in Solana should be able to use a common program similar to


"use a common program" -> "define an instruction"?

@garious not really define, how about: "reuse the same code and state machine"

book/src/generalized-ownership.md

garious · 2019-03-13T15:36:35Z

book/src/generalized-ownership.md

+enum OwnerState {
+    // the owner identity must provide a valid signature for this pubkey
+    Unique {
+        // The actual owner key.


"actual owner" is a strange thing to say. Smells of a terminology problem. Is there a "not-actual owner" that's hijacked the term "owner"?

Account has an owner, which is the program. Signer, which is the thing that owns the some keypair. The owner of the state which stores these bits, which is irrelevant here. How about token_owner, or unit_owner?

I can't help specialize vague terminology. I asked because I can't tell what you're referring to. I need you to spend some time either thinking on the terminology and defining it earlier in this document, or spend more time clarifying the problem statement and have others propose solutions.

garious · 2019-03-13T15:37:28Z

book/src/generalized-ownership.md

+### OwnerState::Transfer
+
+* account[0] - RW - The OwnerState.
+* account[1] - R - Current owner Pubkey, needs a signature. Doesn’t need an


A credit-only account needs a signature?

Yep, it just needs to show proof of owning the identity. Kind of interesting, since this account doesn’t need an actual balance

Personally, I'd accept tokens from anybody giving tokens out - my signature is not required.

aeyakovenko · 2019-03-13T16:12:16Z

@garious, want to work on this together? It would be nice to split this up into a semi group and a monoid.

garious · 2019-03-13T16:19:27Z

@aeyakovenko, I'd prefer not to work on this until you create an GitHub issue that describes the problem in detail, such that we can prioritize it. It's likely that I'll want to write a design proposal of my own and maybe implement it too. The MapReduce possibility is something that we've been talking about since the earliest days of the project.

book/src/generalized-ownership.md

wip design cleanup zero items fixup! zero items fixup! zero items update grammarly put the problem up front wip

aeyakovenko · 2019-05-19T16:43:07Z

@garious let’s move this forward. Dealing with external settlement depends on this.

garious · 2019-05-20T02:09:12Z

@aeyakovenko, can you explain how dealing with external settlement depends on this?

aeyakovenko · 2019-05-20T02:15:39Z

@garious the example in the doc discusses how two external assets get traded by an exchange program. The alternative is a single non-generalized exchange that only understands the tokens and external assets it was initially programmed with.

garious · 2019-05-20T23:23:38Z

@aeyakovenko, I wonder if the fundamental problem here is in the Token program. It decides what to do based on data in Instruction.data. Instead, what could be in Instruction.data is TokenInstruction::LoadInstructionFromAccount. If so, an "analyst" program would accept a TicTacToe account and use that state to store a TokenInstruction into an account that it owns. The Token program would then load a Transfer instruction and proceed as it normally would. The message would be written as such:

let transfer_ix = token::transfer(42, &carol_id, &dan_id);
let message = Message::new(vec![
    ttt_instruction::move(&alice_id, &game_id, 2, 2),
    system_instruction::create_account(&gambling_greg_id, size_of(transfer_tx)),
    tttanalyst_instruction::when_winner(&gambling_greg_id, &game_id, IS_X, transfer_ix),
    token_instruction::load_instruction_from_account(&gambling_greg_id),
]);

client.send_message(&[&alice_keypair, &gambling_greg_keypair, &carol_keypair]);

aeyakovenko · 2019-05-20T23:29:47Z

@garious, it needs to lock the tokens from transfer while their are in play. In the design it’s covered as OwnerState::Escrow

garious · 2019-05-20T23:30:35Z

In fact, that last instruction can be generalized for all programs if recognized by the runtime:

system_instruction::load_instruction_from_account(TOKEN_PROGRAM_ID, &gambling_greg_id)

aeyakovenko · 2019-05-20T23:39:02Z

@garious, ah I see. You are looking at the output of the previous instruction. You can do that with atomics. Configure the token program to payout the result based if an instruction is called with the right keys in the same TX. it doesn’t even need to look at the state, just Succeed.

That doesn’t compose. The token program needs to have those hooks. Everyone implementing a token must add them, since it’s sync for that state transition. I can’t add additional tokens and gamble them in tic-tac-toe against other token programs.

aeyakovenko · 2019-05-21T04:40:29Z

@garious I don’t see where the chain enforces that the transfer occurs if and only if the winner won

garious · 2019-05-22T16:22:00Z

@aeyakovenko, yes, that's not obvious. It'd be implemented by this line:

tttanalyst_instruction::when_winner(&gambling_greg_id, &game_id, IS_X, transfer_ix)

What it's saying is that the analyst is analyzing the game_id account to see if X won, and if so, storing transfer_ix in gambling_greg_id, and otherwise storing a no-op.

garious · 2019-05-22T16:37:03Z

The big limitation in my example is the lack of an escrow account. What's awkward there is that the escrow account would be owned by the token program, whereas the contract controlling them would be held by tttanalyast, which cannot sign a token transfer transaction.

Your suggestion of a predicate language in token is one way to move forward, but feels like a long rabbit hole. I'd rather have token delegate ownership to a program, which is already part of this proposal. Let me think on the possibility of making that delegation the only new feature.

aeyakovenko · 2019-05-22T19:20:12Z

@garious think there are two ways,

token escrow on (program, instruction, keys)
if the tx executes, the transfer occurs to data held in one of the keys

or

token escrow when an Account::data transitions from 0 to pubkey
when the account is non-zero, the escrow can change the owner to pubkey

garious · 2019-05-23T02:28:07Z

I don't understand what you're saying there ^^^

garious

I'm not optimistic that I'm going to grok this proposal if only incrementally moved forward in response to my review comments. I think this will either require another brain or a rewrite. If a rewrite, I'd suggest way more content in the problem description and less code in the proposed solution.

garious · 2019-05-23T02:29:57Z

book/src/generalized-ownership.md

+The goal of this design is to make the following possible:
+
+In a single program, it should be possible to change and update ownership of
+arbitrary units of tokens implemented by other programs.


This sentence is unclear - specifically "ownership" and "arbitrary units".

garious · 2019-05-23T02:32:15Z

book/src/generalized-ownership.md

+
+## General idea
+
+For items to have externally countable ownership, they must rely on the external


This looks like the first use of "externally countable ownership". What does it mean?

garious · 2019-05-23T02:33:47Z

book/src/generalized-ownership.md

+
+## General idea
+
+For items to have externally countable ownership, they must rely on the external


What do you mean by "items" and "units" exactly?

garious · 2019-05-23T02:34:41Z

book/src/generalized-ownership.md

+## Generalized owner identity
+
+Using the account's pubkey identity as the asset owner identity means that all
+the asset transfer APIs must be re-implemented by the program code.


That looks like an overreaching assertion.

garious · 2019-05-23T02:35:54Z

book/src/generalized-ownership.md

+Using the account's pubkey identity as the asset owner identity means that all
+the asset transfer APIs must be re-implemented by the program code.
+
+The proposed solution is to use a pointer to an owner identity.


This is using ambiguous terminology.

garious · 2019-05-23T02:48:58Z

book/src/generalized-ownership.md

+```rust,ignore
+// This state is owned by the MyTokenState
+struct MyTokenState {
+    // This points to an OwnerState structure that identifies the actual owner


actual owner

garious · 2019-05-23T02:49:15Z

book/src/generalized-ownership.md

+
+## Programmatic Transfer of Ownership
+
+Currently, programs have no way to trigger a transfer of ownership. A game of


garious · 2019-05-23T02:49:30Z

book/src/generalized-ownership.md

+## Programmatic Transfer of Ownership
+
+Currently, programs have no way to trigger a transfer of ownership. A game of
+TicTacToe has no way to assign a prize to the winner.


assign or award?

garious · 2019-05-23T02:50:14Z

book/src/generalized-ownership.md

+
+```rust,ignore
+// This state is owned by the Owner program
+enum OwnerState {


Another definition of OwnerState? Are these progressively more advanced definitions? Perhaps this was all the same OwnerState definition and each field was introduced as a full OwnerState definition?

garious · 2019-05-23T02:51:15Z

book/src/generalized-ownership.md

+An offer to trade:
+
+```rust,ignore
+Trade {


Where is Trade defined?

rob-solana · 2019-06-05T20:00:53Z

book/src/generalized-ownership.md

+// This state is owned by the MyTokenState
+struct MyTokenState {
+    // This points to an OwnerState structure that identifies the actual owner
+    owner: Pubkey,


why is a pointer to the OwnerState needed in this struct?

aeyakovenko · 2019-06-05T20:26:22Z

I am going to split this out into two problems.

generalized ownership
cross program state transitions

garious · 2019-06-13T15:52:02Z

@aeyakovenko, can this be closed in favor of #4603?

aeyakovenko · 2019-06-13T16:02:32Z

@garious want to file another Issue that captures the problem of delegating scarcity to a Token program? And a way to delegate transfer of ownership to other programs from within the Token program?

garious · 2019-06-13T16:26:03Z

@aeyakovenko, in that model, you don't delegate. It's permissionless. You'd spin up a token to represent some other set of tokens, and then stake and trade with the new token. How about tickets for demos of various usecases you propose? I'm working towards betting on tic-tac-toe outcome with a Token. After that, the other example you give here, of swapping two Tokens. Looking for others?

garious · 2019-06-13T16:35:47Z

@aeyakovenko, sounds like your solution must be addressing more problems than what you've provided. You mentioned splitting this proposal into two earlier. Sounds like we'll need that sooner than later. If so, can you do that with issues instead of PRs?

garious · 2019-08-12T21:40:55Z

@aeyakovenko, this PR is very old and hasn't gotten traction. Can we close it for now?

aeyakovenko · 2019-08-12T23:52:06Z

@garious closed. We are moving too slowly for general purpose tokens. Maybe stakes will be the first consumer.

* SVM: use lps from `FeeStructure` directly * SVM: rename `lamports_per_signature` to `blockhash_lamports_per_signature` * program-runtime: rename `lamports_per_signature` to `blockhash_lamports_per_signature`

aeyakovenko requested review from jackcmay, mvines and CriesofCarrots March 11, 2019 05:25

aeyakovenko changed the title ~~Generalized ownership~~ Add design proposal for generalized ownership Mar 11, 2019

garious reviewed Mar 12, 2019

View reviewed changes

book/src/generalized-ownership.md Outdated Show resolved Hide resolved

garious reviewed Mar 13, 2019

View reviewed changes

aeyakovenko mentioned this pull request Mar 13, 2019

User defined tokens cannot be transferred and exchanged by other user defined programs #3266

Closed

aeyakovenko commented Apr 14, 2019

View reviewed changes

book/src/generalized-ownership.md Outdated Show resolved Hide resolved

aeyakovenko mentioned this pull request Apr 15, 2019

HTLC Proposal #3709

Closed

garious force-pushed the generalized_ownership branch from 093730f to 983215b Compare May 6, 2019 20:57

wip

a7c3a51

wip design cleanup zero items fixup! zero items fixup! zero items update grammarly put the problem up front wip

aeyakovenko force-pushed the generalized_ownership branch from 983215b to a7c3a51 Compare May 10, 2019 20:24

aeyakovenko added 2 commits May 10, 2019 13:24

fixup! wip

7332c91

fixup! fixup! wip

64a59ea

aeyakovenko requested a review from garious May 19, 2019 16:41

garious reviewed May 23, 2019

View reviewed changes

aeyakovenko mentioned this pull request May 28, 2019

Add design for structured accounts as an alternative to Generalized Ownership #4452

Closed

rob-solana reviewed Jun 5, 2019

View reviewed changes

aeyakovenko mentioned this pull request Jun 13, 2019

Lack of a single trusted reusable program that implements scarcity #4672

Closed

aeyakovenko mentioned this pull request Jun 23, 2019

Add a design for the Pipeline to support Move like Resources #4785

Closed

aeyakovenko closed this Aug 12, 2019


		## General idea

		For items to have externally countable ownership, they must rely on the external


		## Programmatic Transfer of Ownership

		Currently, programs have no way to trigger a transfer of ownership. A game of

Add design proposal for generalized ownership #3216

Add design proposal for generalized ownership #3216

Conversation

aeyakovenko commented Mar 11, 2019 • edited by garious Loading

Problem

Summary of Changes

garious left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aeyakovenko commented Mar 13, 2019

garious commented Mar 13, 2019

aeyakovenko commented May 19, 2019

garious commented May 20, 2019

aeyakovenko commented May 20, 2019

garious commented May 20, 2019 • edited Loading

aeyakovenko commented May 20, 2019

garious commented May 20, 2019

aeyakovenko commented May 20, 2019 • edited Loading

aeyakovenko commented May 21, 2019

garious commented May 22, 2019

garious commented May 22, 2019

aeyakovenko commented May 22, 2019

garious commented May 23, 2019

garious left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aeyakovenko commented Jun 5, 2019

garious commented Jun 13, 2019

aeyakovenko commented Jun 13, 2019

garious commented Jun 13, 2019

garious commented Jun 13, 2019

garious commented Aug 12, 2019

aeyakovenko commented Aug 12, 2019 • edited by garious Loading

aeyakovenko commented Mar 11, 2019 •

edited by garious

Loading

garious commented May 20, 2019 •

edited

Loading

aeyakovenko commented May 20, 2019 •

edited

Loading

aeyakovenko commented Aug 12, 2019 •

edited by garious

Loading