[discussion] Dynamic "Naming" Contract Network

Jam10o

Namecoin was a good idea, but it suffers from many flaws due to its DNS-based architecture, it's single block chain, and of course, the fact that it is based on the bitcoin block chain, limiting it's flexibility somewhat.

A few issues typical of the todays DNS systems (*but not Namecoin) are as follows:

"Parked" domains and hoarding
Man-in-the-middle attacks*
Government-based censorship*
Commercial DNS redirection*
Tracking and traffic analysis*
Limited to specific domains

As you may know, Namecoin is one solution to Zooko's Triangle, that is, addresses are secure, memorable, and global as well. The traditional DNS system is close, but not quite global due to consensus issues and censorship.
Namecoin is also easily susceptible to hoarders and "parked" websites caused by the way it is modelled on ordinary dns servers. It is also, by nature, impermanent due to the irreversible loss of coins upon creation of an address.

It is fairly simple to build a system that circumvents these issues and builds upon the decentralized and flexible nature of the Ethereum blockchain. Please let me know if you have any ideas for the following potential project.

If the implementation is based on Namecoin, we would have a single "name contract" and Ethereum would be spent in creating new addresses within the contract, the memory of which could quickly balloon and become costly in terms of processing power. On the Ethereum blockchain, a single name contract would be inefficient, due to these increasing costs.

Ie, the first address added would cost x ether to add to memory (including checks on whether it already exists, which grow as the number of addresses increase) , the nth address could therefore cost significantly more than the first. This may be a good thing, in that it prevents a exceedingly large number of addresses to be claimed for no content, but disproportionately benefits early users and domain trolling, which are both significant problems with Namecoin and the DNS system.

In an alternative situation, there are many "name contracts" with relatively small memories, and trust relationships between them.

Ie,
A contract, [internally] named "hello" acts as a root server to a hypothetical user.
The contents of the memory of a contract can be used to either point to resources on or off the blockchain.

In the case of the "hello" contract,
(0,"hello", "[own contract address]")
(1,"jam10o", "[other name-contract address ]")
(2,"world", ("ethereum.org")
(3,"...", "... ")
etc..

Users can select their own root contract, and gain access to all contracts and addresses it links to. Name contracts can either
a) accept "submitted" addresses with address deletion controlled by a "moderator" or muiltiple moderators, using a scheme similar to the DAC example in the wiki,

Or

b) be completely under the control of a single owner (such as, hypothetically me, owning the Jam10o name contract example above).

In the case of the above contract, the URL hello:world points to the Ethereum homepage. These relationships could be used to create a chain to any resource defined in any compatible contract, given the network is sufficiently linked. Potentially, it could also introduce annoying recursive urls, such as hello:jam10o:hello:jam10o:... ...:hello:world or, if contracts do not "return" links, an issue of "non-reversible" urls may come into play (hello:jam10o is valid, whereas jam10o:hello is not).

Using these contracts, anyone who needs to can own their own vanity url that is both memorable, secure, and globally accessible (with certain caveats) due to the need to have contracts link to each other. An unsavoury character may "park" muiltiple contracts on the blockchain, but without any users finding utility in them, their contracts will be "orphaned" from the web, which may act as a web of trust. A trusted user who provides utility to the community however, will certainly be linked by muiltiple contracts, increasing their visibility and traffic. Content may be self-censored in this manner, however due to the fact that the "censored" contract is still on the blockchain, it can still be easily accessed.


Therefore you have an un-censorable, but still moderatable and safe, dynamic naming system. Name resolution would need to be handled by an external client, which is why I put this in the "Projects" section of the forum:
A successful implementation of this system relies on a few elements:
A standard structure for participating contracts
An external DNS server linked to the Ethereum blockchain, capable of parsing the links between contracts
[and at some point in the future, a protocol that allows users to connect to one another without interception. Cjdns integration anyone?]

I'd love to hear what anyone has to say about this idea, feel free to implement it on the blockchain on release if it seems doable for you, (as the code will undoubtedly be reused by others). Discussion on possible contract standards, dns servers, and criticism of any flaws in the concept is welcome.

giannidalerta

A trusted user who provides utility to the community however, will certainly be linked by muiltiple contracts, increasing their visibility and traffic.

What happens if the unsavory character can generate thousands of contracts that point to the one entry, thus providing a false perception of utlity. Much like people would do with doorway websites to influence website indexing on search engines.

I see what you are saying though, I see it like a torrent tracker, once there is no more need for it, it disappears. So the person is obliged to make it "interesting" if not it disappears.

sneurlax

In the case of the above contract, the URL hello:world points to the Ethereum homepage. These relationships could be used to create a chain to any resource defined in any compatible contract, given the network is sufficiently linked.

Could you clarify this a bit more?

Let me see if I understand you correctly: let's say I create a contract "sneur" that is compatible (format/protocol-wise) with your contract "hello" above. The first address I register in sneur is "lax", of course, which links to my private webpage. Now, you don't explicitly mirror all the data in my contract, but you come to value our hypothetical future friendship and so deign to register an address that forwards to my contract. Thus, your users can type hello:sneur:lax and access my webpage just fine?

I don't know if you've thought of this (or if it's what you meant,) but a useful addition that I would add to my own brand of name resolution contract would be a feature to trust other such contracts; that is, as in the previous example, if I chose to trust your hello contract (based on the utility you provide,) then my contract would first search its own internal memory for an address but, failing that, would route it on to its trusted fellow name-resolution contracts. For example: I link hello in sneur as a "trusted" name-resolution list. Thereafter, users can simply input sneur:world to access "ethereum.org", even if sneur never explicitly refers to world.

I hope I haven't been obtuse.

Jam10o

What happens if the unsavory character can generate thousands of contracts that point to the one entry, thus providing a false perception of utlity. Much like people would do with doorway websites to influence website indexing on search engines.

The concept is to make it very costly to do exactly what you described. Sure, a malicious user can create a massive Web of contracts to funnel traffic to them, however unless they are described in a contract that is *not* under their control, it is just free ether for miners, and no benefit to them.

Now, you don't explicitly mirror all the data in my contract, but you come to value our hypothetical future friendship and so deign to register an address that forwards to my contract. Thus, your users can type hello:sneur:lax and access my webpage just fine?

That's the idea. In your example, if you wanted to access "sneur:lax" and you were only explicitly connected to "hello", you could do so using "hello:sneur:lax" assuming "sneur" was listed by "hello". Different types of contracts may solve the other problem you seem to be alluding to. Another kind of contract could be one in which any user can pay a fee in order to have a contract listed, although this opens up a series of issues of its own (namely, parking, again...) , it will likely be the most common contract as operators can potentially make a profit from running a widely used one.

The actual resolution of the contracts would be best left to an off-chain client, and different policies for resolution could be easily implemented as features of this application as opposed to the contracts themselves, which will ideally just be data storage with edit controls.

For example: I link hello in sneur as a "trusted" name-resolution list. Thereafter, users can simply input sneur:world to access "ethereum.org", even if sneur never explicitly refers to world.

That would be great, but as in any trust based system, it could have repercussions ie, bob trusts hello, which has a trusted path to jerry who has a different friend called bob. Unless of course, bob only accepts addresses directly in hello, in which case he all trust in hello must be ignored. This could cause confusion between different policies, and what good is a url if you can't share it?

sneurlax

I'm very interested in implementing pretty much exactly what you've outlined. I'm going to be researching ECLL and drafting the contract code soon--after reviewing as much about Ethereum as I can, of course (but I have to say that so far I'm smitten: it's exactly what I've been contemplating doing, except the execution and capabilities of the team so far seem superior to my own talents.)

What say we start hashing out a format so that we can maintain some sort of compatibility like you mentioned? Nothing has to be binding, of course, but I'd rather be compatible with someone else than a hermit.

Jam10o

That's perfect If you have read up about the RLP specification used in Ethereum, you may have noticed the similarities between the example format I used, and the list/item structure used in the specification.

(0,"hello", "[own contract address]")
(1,"jam10o", "[other name-contract address ]")
(2,"world", ("ethereum.org")
(3,"...", "... ")

Any thoughts?

FreddyFender

The cost involved utilizing the Ethereum Blockchain for all Txs on an alt DNS is extensive and probably prohibitive. There are other solutions available... me thinks?

sneurlax

Well we'd have to see after the contract was authored and the blockchain running, wouldn't we? For me it would come down to: is it more expensive to run it on Ethereum, or to run a dedicated DNS blockchain?

Jam: I think that at least four keys are needed: an index (obviously,) label, address, and contact address. Now, the contact address can be optional, but I think it should be available and encouraged (so label owners can be contacted, but don't have to include to information if they don't want to.)

so ( 0, 'hello', '[own contact address]', '[email]' )

sneurlax

I think that these could be expanded by, for example, including a protocol associated with the address (http, ftp, https, bittorrent magnet, tor, i2p, etc. etc.) and a protocol associated with the contact (email, bitmessage address, IRC channel, facebook profile, skype, etc. etc.) -- or, better yet, allowing arrays to be stored, such that users can request "hello" but allow their client to select the most appropriate protocol/address available.

giannidalerta

sneurlax, based on Chris Oden's open transactions library that will work with Ethereum, he has a federated server model where there servers have no trust and just notarize the contracts. Could that be used in your DNS server example. (Pardon my naivete as I am not a coder)

Your last post is pretty mind boggling even though my non dev mind cannot decipher how something like that would work on a technical side. If I understand it correctly it means that there would be no need to specificity the full address as it would auto select.

That my new found forum friend blew my mind.

This could then be applied to other aspects like VOIP/SIP as a protocol, as you mentioned there is still and issue with latency. The more I think about your comments, I could even see a decentralized TV as I had been reading recently about Bittorrents bitstream project.

Thanks for sharing your thoughts, helps non developers get a bit deeper with the ideas.

Jam10o

I can't see any situation where this would need to be moved to a separate blockchain, adding simple strings to the memory of a contract is relatively cheap (compared to alt-coins, which would be more calculation-intensive)

sneurlax: I didn’t think about adding contact addresses, but it does seem reasonable. That and specifying protocols.

How about this? A rough draft of the first link in "hello" (In pseudo-RLP)
[0x84, 0x00, 0x45, 'h', 'e', 'l', 'l', 'o', 0x82, "protocol", "address", 0x82, "protocol", "address"]

Or to make it less convoluted
The entire item is a list of four items, the first is the index, followed by label, followed by a two-item list containing protocol(s maybe? As a list within this list?) and address, followed by contact details in the same format. This should give enough flexibility, and can easily be extended with new features in the future by adding more keys or nesting lists.

sneurlax

List-within-a-list is probably the best way to do it if ECLL allows for it. A client could then either request the whole entry (and get a list like [ "blurb.com", "http"; "[email protected]", "email" ], which it would select which is best based on the context) or a specific subset (just the http entry of the subarray.)

I don't know if key => entry arrays are possible in ECLL, but if http => blurb.com isn't possible then we can just code in that i is the address and i+1 is the protocol, etc. etc. -- same situation is ECLL doesn't allow for subarrays, it just makes things less elegant (imo.)

So, address-first ([ "blurb.com", "http"; ]) or protocol-first ([ "http", "blurb.com" ])?

giannidalerta: a quick google search fails to return any joy on Chris Oden open transactions library. Mind sharing a link?

Jam10o

My vote is for protocol first, as it would make it easier to implement contextual items for (if only in human-readability, and the fact that protocols tend to go first ie https://[url] which means it may reduce confusion).

FreddyFender

gianni, I have done some extensive investigation of this issue and have a less technical background then Jam10o and sneurlax. We should start a additional thread for OT integration and testing with ethereum. I will let jam/sneur continue this terrific thread. we'll just borrow some of their ideas and report back.

sneurlax

protocol-first sounds good. I've been very strapped for time lately (taking Thermodynamics consumes me,) but as soon as I find some good guides on ECLL I'll start laying stuff down.

Jam10o

Posting some framework code as an edit to this post later today.

Jam10o

Can't find the edit button (60 min limit) . Meh.
I based this off of the DAO example in the whitepaper, but in doing so, I noticed that the "exit" (on the ECLL wiki page) is "stop" in the whitepaper. Not really an issue. Would like some clarification though...

Contract accepts transactions only above 300 times the base fee (very rough overestimate of how much it actually needs..) FORTUNATELY it includes a feature to "withdraw" funds back to the owner. No "duplicate label" checks (yet).

Transaction data sent to the contract (from anyone granted permission) is in the format of [command, index, data] an owner can grant permission to any other person by setting their "index" to the address of the new editor, and "data" to "1". Available commands are adding to memory (1) removing from memory (0) and withdrawing ether (2)

"data" would normally be the structure described earlier, minus the index presumably, since it's in the transaction data?
This contract also acts as a "shared" storage of arbitrary data and units of ether.

This is a very rough draft, and if I've made any obvious errors in syntax or anything, please correct me.
Here we go //comments. [why the hell am I doing this on my phone... sorry about the space/tabs... ]

---

if tx.value < tx.basefee * 300:
//arbitrary value limit
 stop
else:
//check if you have permission to edit
if contract.storage[tx.sender] == 0:
 stop
else:
//delete command
 if tx.data[0] == 0:
  contract.storage[tx.data[1]] = 0
  stop
//save command
 else if tx.data[0] == 1:
  contract.storage[tx.data[1]] = tx.data[2]
  stop
//withdraw contract contents
 else if tx.data[0] == 2:
  mktx(tx.sender, (contract.balance - tx.basefee * 100))
  stop
//using same magic number as vbuterin to check if this is the first run.
//first owner is hard coded. contract can be returned if magic number is restored to 0.
//(or deleted in order to gain the refund fee). your contract will come back to you... Someday.
if contract.storage[2^255+1] == 0:
 contract.storage[2^255+1] = 1
 contract.storage[*insert owner address here*] = 1
 stop

---

Jam10o

note, tx.sender in line 19 can be hardcoded to the owners address, if you don't want people with permission taking your ether.

Jam10o

To do/Wanted: (can anyone help) build the external client to parse name data from contract memory and be used as a dns server.

Jam10o

Woot! I got the compiler from pyethereum to work, (after some tweaks...) many kudos to @vitalik for his fine work

Ethereum script for above contract as follows:

TXVALUE PUSH 0 MLOAD PUSH 300 MUL LT NOT PUSH 128 JMPI STOP PUSH 128 JMP PUSH 1 MLOAD NOT PUSH 128 JMPI PUSH 2 PUSH 255 EXP PUSH 1 SUB SLOAD PUSH 0 EQ NOT PUSH 47 JMPI PUSH 1 PUSH 2 MLOAD SSTORE PUSH 1 PUSH 2 MLOAD SSTORE TXSENDER SLOAD PUSH 0 EQ NOT PUSH 128 JMPI STOP PUSH 128 JMP PUSH 3 PUSH 0 ADD MLOAD PUSH 0 EQ NOT PUSH 128 JMPI PUSH 0 PUSH 2 MLOAD SSTORE STOP PUSH 128 JMP PUSH 3 PUSH 0 ADD MLOAD PUSH 1 EQ NOT PUSH 128 JMPI PUSH 3 PUSH 2 ADD MLOAD PUSH 2 MLOAD SSTORE STOP PUSH 128 JMP PUSH 3 PUSH 0 ADD MLOAD PUSH 2 EQ NOT PUSH 128 JMPI PUSH 4 MLOAD PUSH 4 MLOAD PUSH 4 MLOAD TXSENDER MKTX STOP

Now I have to figure out how to get this on the blockchain once I'm sure the blockchain is accepting contracts.

yoyo

Sorry to be late to the discussion but I want to address something in the very first post :

Jam10o wrote:
"the first address added would cost x ether to add to memory (including checks on whether it already exists, which grow as the number of addresses increase) , the nth address could therefore cost significantly more than the first."

I don't think that is necessarily true. You could simply do a hash of the address and store the corresponding name at the contract storage slot corresponding to the hash. The cost of the verification is always O(1), basically using the permanent storage as a hash table. (possibly with an offset to avoid overwriting contract code).

With this, a single contract is sufficient to store your entire name registry. It doesn't have the same properties of your proposition though, as it is unmoderatable. But it might be a useful construct for other registries.

Jam10o

that's a helpful point the highlight of the concept is that it is decentralized though, but the hash idea could help lower the costs anyways.

sneurlax

Sorry for my several-day absence; nice work on the ECLL.

Few questions: So the functions are 0 => delete, 1 => save, 2 => withdraw?

Why not just have 0 => edit, where to delete the entry you just set it to 0?

Why not just have it automatically refund the excess ether to the last sender?

Any word of how to / if we can store arrays?

One thing I thought of over the weekend is how we'll link contracts. How about using a function similar to a symbolic link (symlink?) We can add the contract address and perhaps use "contract" or "symlink" as the protocol. Or should linked contracts be in their own array instead of interspersing them throughout the name/address values?

Should we add some "date-registered" value? This would allow, for example, a functionality that could resolve address conflicts between linked contracts by returning the earliest-registered address.

Jam10o

About arrays - RLP has that handled, as long as the entire item is less than a certain size (that I don't remember off the top of my head).

About refunds - this happens in a root contract I'm working on now, doesn't happen in this contract because it's intended to only have a single user.

About dates - we don't have access to time, but we can add a simple counter (increases by one every transaction)

About links - as in the "protocol" space? Yep, we'd have to denote the protocol, and it would be simpler to use the same name/address notation.

Check out the github repo I threw together (todo ones exist, but aren't quite there yet)

https://github.com/jam10o/contracts

VitalikButerin

@Jam10o: if you found some bugs in the compiler, please do make a pull request, and I'll put it into the main repo.

exit and stop are synonyms for now; but the ECLL and ES are still being worked on so that might change.

> I don't know if key => entry arrays are possible in ECLL

Just use arr[sha256(key)] = val and you got it (although there isn't a way to loop through/enumerate keys); it's ugly but it works since the probability of a collision is essentially zero.

Jam10o

I just thought I'd give a quick update on my plans and progress if anyone wants to know what's going on with this idea.

Name-contracts (done! By quite a few people already!)
Parsing Name-contracts (already implemented by Gavin Wood in Alethzero with his name registration contract)
"Mapping" contracts (I'm working on this! Stay tuned for something that works with the current client in the next few weeks. I have no idea what I'm doing but I'll get it done.)
Initial DNS/Namecoin support (shortly after the above gets done.)
Initial meshnet support(shortly after above, again.)
Update for whatever the canonical format will be for writing plugins to the client (whenever this is announced, hopefully before the mainnet is released.)
Quick security audit, and bug-squashing and initial "realease" of the full software (prior to mainnet release, ie Q3/Q4 this year.)

If anything, I'll be using this because I find it cool and it'll let me build a small VPN (if not a fully blown meshnet) with my own machines.

Please PM or comment if you feel like speeding this timeline up any help is highly appreciated. (especially in helping me learn the skills to work on this further.)

Some pretty pictures incoming once I get to my work machine

krasi69

Hello All, this is a great project ! So can I register new domains through Ethereum ? Is there any user interface similar to GoDaddy.com ? I am not a programmer so a web interface will be very helpful for me.

Jam10o

Not yet, unfortunately (note: yet). When ethereum does replace the internet (I'm only half kidding here..) I'm sure that there will be plenty of go-daddy like services for ethereum domains .

Jasper

Having the names distributed over different contracts doesnt really lower the storage costs at all. One way to maybe decrease storage costs is to have the contract somehow be able to take its own data and stuff it all in a single data structure, and then store the Merkle tree. As it does that, people can make a copy of the actual thing. The contract itself wouldnt know what the names are, but anyone with a copy can prove to it that particular bits of the data are a particular way. If data(like names here) is particularly static, and there are people that would actually challenge it, that may be useful.

Merkle trees might also be an approach to avoid hoarding on all the existing domain names; put a Merkle root of the name in. However, this leaves us with the awkward problem of trying to figure out if some dude claiming that he has the domain name actually does have it.. Perhaps we can use the public key if a site uses SSL, much doubt that being fool proof!(but at least the thought behind it is potentially trustless)

Zaki Manian makes a good point in Ethercasts.

In discussions on skype some have been worries about the of Ethereum creating the top NameReg. Only now i realize that this post might be what other others were talking about.

Main issue with your approach is that, the point of naming systems like namecoin is that human readable names relate to the same things for different people. Having people choose different name registries isnt conducive to that. I dont think we can afford to have chaos regarding who creates the top namereg. Besides, the top NameReg can be trustless anyway, though there is the problem with hoarding, and i dont really have a good trustless solution to that..

Edit: i suppose you could leave that and say that each page has a list of domain-givers, and those can contain sublists. Not sure what the consequences of that are.

Jam10o

The idea isn't for this to be a generic NameReg, nor is it to create the "top NameReg", as those were established fairly quickly by the core team: It's more an experiment into the practicality of a "social" naming system; when you think it through, allowing contracts to reference each other alongside external resources creates what amounts to a social graph (with contracts as nodes).

I accept the point that in any practical implementation, having people choose different "top" servers will cause confusion from the perspective of an internet user. I couldn't reliably or safely, say, give the url to a website to a friend who has chosen a different top server than me. But knowing this, given the (potentially pseudonymous) identity of a friend, I can find the exact resource the friend is referencing; it isn't an issue of "choosing" a NameReg, it is one of entirely controlling your own.

There will certainly be multiple implementations of name registration on ethereum, in different data structures, with varying levels of trust or security. Trustless implementations will always be vulnerable to gaming and hoarding; whereas trusting someone else with your DNS will be hard for those conscious of security or censorship. The concept here is to let anyone be their own registrar (and ideally, create a system that is more flexible, or at least interesting, than the current web). Chaos is a feature here

Jasper

Well trustless NameRegs can protect themselves from hoarding somewhat. For instance an particular amount of payment per time unit, perhaps compensated for usage. (i.e. valid users may need to change addresses anyway, so you can make the service effectively cheaper for real users by substracting the cost of doing so) Forced sale if you pay over a factor of two, probably too caurse.

Just because it is not trustless doesnt mean it is untrustworthy, or that you need 'very focussed' trust. You can 'trustlessly' have a democracy of some kind, but you still need to trust the members not to vote for awful things. This could also apply for lists the top registries might use to try avoid hoarding with respect to existing domain names.

I think the word 'established' sounds more final than the NameReg code is... It was put onto the testnet, and made central for the client. That doesnt have that much finality to it! It certainly isnt the same code that will be uploaded on the live net.