ERC: Owned Standard

[danfinlay]

Opening discussion to nail down semantics for a common pattern that should be standardized.

Many smart-contracts have adopted some pattern of representing the ownership of that contract, and it's such a common and simple pattern, that the exact phrasing should be standardized into an Application-layer protocol, to allow leveraging cross-compatibility.

This standard could be called the Owned standard. I've also heard it called the Asset standard. The standard defines at least one method, either:

• setOwner(address _newOwner)
• transferOwner(address _newOwner)

This might be paired with an event, maybe called OwnerTransfer.

It would also probably benefit from having a support method, either one of:

• getOwner() returns address
• owner() returns address
• isOwner(address _owner) returns bool

Places I've seen this used

• AuctionHouse, a Dapp that allows users to auction any on-chain asset adhering to their own Asset protocol.
• The proposed Proxy Standard includes a loose implementation of this standard.
• The Dapple DSAuthorized class essentially implements this pattern.

You can read a more formally specified version of this proposal here:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-173.md

[apmilen]

could transferOwner be replaced with setOwner ? Then it would be nicely paired with getOwner

[danfinlay]

I like it. I added it as the new first option.

[SilentCicero]

@FlySwatter this is super needed, nice, we do need standards across the board for this.

[dob]

Author of the AuctionHouse Asset protocol here. I wanted to point out that it's a little different then what is proposed here. The idea behind the Asset protocol was not that the contract itself was owned or transfered, but that the records tracked within the contract, identified by string _recordId, were owned or transferred.

So for example, a contract:

contract VirtualGoodPlatform is Asset {
  struct VirtualGood {
    address _owner;
    ...;
  }
  mapping(string => VirtualGood) registry;   // Maps the record ID to the good
}

getOwner(_recordId) and setOwner(_recordId, _newOwnerAddress) would update the registry, and not actually update ownership of the contract.

I think settling on a standard for the above is important so that we can have common implementations of trading, buying, selling, and transferring non-fungible assets. But it may be a little different than what you're suggesting here in terms of contract ownership itself. Yes?

[danfinlay]

Yes, I guess so!

On Nov 8, 2016, at 5:21 AM, Doug Petkanics notifications@github.com wrote:

Author of the AuctionHouse Asset protocol here. I wanted to point out that it's a little different then what is proposed here. The idea behind the Asset protocol was not that the contract itself was owned or transfered, but that the records tracked within the contract, identified by string _recordId, were owned or transferred.

So for example, a contract:

contract VirtualGoodPlatform is Asset {
struct VirtualGood {
address _owner;
...;
}
mapping(string => VirtualGood) registry; // Maps the record ID to the good
}
getOwner(_recordId) and setOwner(_recordId, _newOwnerAddress) would update the registry, and not actually update ownership of the contract.

I think settling on a standard for the above is important so that we can have common implementations of trading, buying, selling, and transferring non-fungible assets. But it may be a little different than what you're suggesting here in terms of contract ownership itself. Yes?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Smithgift]

I suggest using only owner() to get the current owner. If you don't need anything special in determining ownership, you can just have address public owner; and Solidity will happily generate a properly-named getter.

[danfinlay]

I agree, it would be good to leverage a public variable for this. Any opinion on the setter name?

[Arachnid]

Shameless plug: ENS can make this pattern obsolete; a contract can do a lookup in the ENS registry for the owner of a given node, and treat that as the owner of the current contract.

[cholewa1992]

My suggestion is

pragma solidity ^0.4.0;
contract Owned {

    address public owner;

    function Owned() {
        owner = msg.sender;
    }

    modifier isOwner {
        if (msg.sender == owner) _; else throw;
    }

    function transferOwnership(address _newOwner) isOwner {
        owner = _newOwner;
    }
}

I use it for a marketplace structure that I'm working on

[danfinlay]

@cholewa1992 The problem I see with that pattern is that you can't easily ask if an arbitrary user is the owner, only if the current user is.

That's why a simple getter (as provided by a public variable) is nice, it's very open ended, and lets the contract speak for itself.

@Arachnid Sorry for not exploring that sooner; So you're saying ENS could make this pattern obsolete if the current owner is registered on ENS, right?

In even that case, the setOwner method would still be useful, and getOwner might still be useful if the contract isn't on ENS.

[Arachnid]

Sorry for not exploring that sooner; So you're saying ENS could make this pattern obsolete if the current owner is registered on ENS, right?

In even that case, the setOwner method would still be useful, and getOwner might still be useful if the contract isn't on ENS.

The idea is that you would look up a predetermined name, and only allow the owner of that name to interact with the contract. There's no need to register anyone; just to set an ENS record.

More generally, it's worth considering extending this model to ACLs in general, not just 'owner'.

[nmushegian]

@FlySwatter the multi-user case should be solved by abstraction in the owner, not by complicating the base class.

Also want to make a comment regarding your examples that DSAuth and the dappsys Authority pattern implements different semantics from Owned and shouldn't be used as inspiration for this standard IMO. Take a look at the most recent version to see how we collapsed the "owner" concept inside DSAuth entirely into the authority, getting out of the way of existing interfaces. We do not want to have a shared ABI with this.

I also strongly favor a minimal variant like the one @cholewa1992 suggested.

[danfinlay]

I think this pattern has been largely canonized in the DS-Auth pattern.

[tymat]

We are using this for DigixCore 2.0 Assets with an additional mint() function which converts the assets into ERC-20 tokens.