Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved Transaction Sender Verification and First Class Assets #1051

Closed
kantai opened this issue Jul 15, 2019 · 3 comments

Comments

@kantai
Copy link
Member

commented Jul 15, 2019

In order to address verification of ownership via transaction sender or origin, we want to provide the following.

  1. First class support for Asset types, which will sidestep the problem of permissions by requiring a "maximum spend of any asset" be included in the wire format for a transaction.

  2. Allow general purpose ownership checks to express a similar range of checks as other smart contracting languages (in EVM, this distinction is made via msg.sender and tx.origin).

1. First Class Assets

Provide two new “define” primitives:

    ;; fungible assets (tokens) do not require a key type -- they are just maps
    ;;   of accounts to balances
    (define-token foo-tokens)
    ;; defining non-fungible assets requires providing a "key type" which will be used to
    ;;   uniquely identify the asset
    (define-asset bar-nfts int)

Then, we have some getters/setters:

    (transfer-token! token-name      amount from to)
    (transfer-asset! asset-name     identifier from to)
    ;; returns balance of fungible tokens or the count of non-fungible assets
    (get-balance asset-name owner)
    ;; returns owner of non-fungible asset, type check error if applied to fungible tokens
    (get-owner asset-name identifier) 

Then, we include in the wire format a set of allowed spends in the transaction. This makes it so that the limit is set outside of the context of the contract execution, and also forces wallet clients to participate in the security measure. The transaction aborts if the allowed spends are exceeded (though, it should be noted, transaction fees would be deducted).

2. Expressing general ownership verification

For general purpose ownership checks, we'll give contracts access to two variables:

  1. tx-sender -- this is the "sender of the transaction", that is the original principal that signed and broadcasted the transaction, unless as-contract has been called, in which case the context switches to simulate the current contract principal signing and broadcasting a transaction (i.e., tx-sender and contract-caller immediately change to the current contract principal).
  2. contract-caller -- this is the most recent caller of the contract. In the first contract called by a transaction, (eq? contract-caller tx-sender) will be true.
@kantai

This comment has been minimized.

Copy link
Member Author

commented Jul 15, 2019

PR #1046 implements the semantics of Part 2 above -- however, the naming is incorrect.

@lgalabru

This comment has been minimized.

Copy link
Member

commented Jul 17, 2019

will token and asset be implemented in rust or clarity?

@kantai

This comment has been minimized.

Copy link
Member Author

commented Jul 17, 2019

will token and asset be implemented in rust or clarity?

I think it has to be in rust -- we'll need interpreter level support in order to perform the whitelisting check.

@kantai kantai closed this Aug 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.