In the latter portion of day 2, attendees of Devcon3 listened to a development update from Swarm as well as presentations on hardware security, Raiden, and the Ethereum Name Service.
On day 2 of Devcon, Swarm’s development team, which is led by Viktor Trón, offered a development update. This included an introduction to Postal Service over Swarm (PSS) and network testing, among other topics. Swarm is “a distributed storage platform and content distribution service, a native base layer service of the Ethereum web 3 stack.”
To date, the Swarm client proof of concept 0.2 has offered relatively slow performance, admitted developers, but the point is that the “basic idea works (yay).” A team member explained how to connect to Swarm, and promptly launched into an overview of how chequebook contracts function. In essence, nodes send data as long as outstanding balances are brought back to zero. Failure to pay results in an imbalance and, subsequently, disconnection. Overall, this mechanism provides an incentive structure for content delivery. However, the scope of the project has moved beyond storage alone.
PSS is an internode messaging protocol, which is under active development. It is available on GitHub in a demo format. This segment was presented by Louis Holbrook (a classical pianist turned taxi driver turned developer). The gist of PSS is that it’s possible to send encrypted messages through a complicated routing overlay and conceal the identity of the recipient. This is accomplished by directing the message to the “neighborhood of the recipient” – essentially the nodes that are in the vicinity of the intended recipient.
The trick is that only the node that can decrypt the message can actually receive and read the message. This is kind of like shouting to get someone’s attention in a subsection of a crowd – except only the person you are trying to reach can hear you. (Wouldn’t that be a weird superpower?) In PSS, senders can select a luminosity control, or how many address bytes to disclose, which seems to affect the message’s level of obfuscation. A neat feature is that by forwarding the message across a bunch of nodes – and not just to the actual receiver – it becomes increasingly difficult for prying eyes to discover or expose the intended target.
With regard to network testing, Aron Fischer explained that the team is examining the “emergent behavior of the client,” including the “subtleties of interaction of the nodes.”
Upcoming changes to swarm included the following:
- A new hashing algorithm for easier proofs of inclusion;
- New syncing protocol; and
- Complete rewrite of the network layer (to be merged soon).
Daniel Nagy talked about the paradigm shift in development from client-server relationships to local front-ends and distributed, generic back-ends. Nagy explained that the use and contribution of resources do not suddenly become balanced in a decentralized application paradigm. Users still have a high churn rate, meaning that they will join and leave a network frequently. These consumers, who possess limited resources, tend to spend their accounting resources. Suppliers, on the other hand, have a low churn rate and high availability. Also, suppliers earn (rather than spend) accounting resources.
Nagy also discussed obstacles to scaling and bottlenecks in the network. Blockchains, he said, are expensive. They require time and storage. And, there is no need to broadcast every transaction to the entire network (this causes congestion). Instead, he explained, users can store root hashes in ENS for swarm sites.
Nicolas Bacca, the chief technology officer for Ledger, spoke about the evolution of smart cards and the best practices for secure hardware (e.g., an isolated environment for code execution and, ideally, physically resistant).
Ultimately, it’s hard to know everything about your hardware – the origin of parts and what might be compromised. In theorizing that hardware wallets are the “next generation of smart cards,” Bacca implored developers to “keep opaque parts as small as possible.”
As many readers know, Raiden is an off-chain scaling solution that aids in making and receiving token payments. It’s also open source. Raiden works on Linux, and the development team is fixing issues with macOS. It does not offer support for Win dows. Also, it’s worth noting that an Ethereum node is required on your machine and you must enable RPC (remote procedure call) to connect to the Raiden Network. There is currently a developer preview available on Ethereum’s Ropsten test network.
The best part of the presentation (by far!) was Robo. Who is Robo? As described by developer Loredana Cirstea, Robo is “the token hungry car,” eager to gobble up off-chain transactions. Robo was connected to µRaiden (read: Micro Raiden) and when the network processed a transaction, Robo zoomed across the stage as directed by Cirstea. Robo sped forward and backward, and at one point, drove onto the base of the presenter’s podium, delighting the crowd.
What was really remarkable about µRaiden was just how fast it was. The essence of µRaiden, as Cirstea explained, is ERC20, off-chain micropayments.
Ethereum Name Service (ENS)
In the final presentation of day 2, Nick Johnson did not disappoint. He outlined the initial spike in demand during the auction of names on the Ethereum Name Service (ENS). In all, 180,822 names were sold for about 168,595 Ether. In an example of just how greedy (or enterprising) some folks are, a full 50 percent of names are held by just 1.4 percent of registrants. Johnson explained that names were divided into more common terms (like those you’d find in the dictionary) and names that were pretty ran dom (and not on this predefined ENS list). The median price of names on the predefined list was 0.05 Ether and the median cost for those names not on the list was 0.02 Ether.
During the auction, 8,553 Ether (or 0.3 percent of total contributions) was lost due to user error and other issues. Also, Johnson pointed out that 35 percent of names on the predefined list received more than one bid, a property that was labeled as “contentious.” Only 7 percent of names that were not on the list received contentious bids.
In August 2017, Johnson hosted an ENS community workshop, where 27 participants gathered to discuss dispute resolution, permanent registrar design, securing sub domains, and DNS integration. At the workshop, Vlad Zamfir suggested a target deregistration rate, which could hopefully alleviate name squatting and replace names that are not in use.
Johnson said that ENS ought to move into a rent-based rather than deposit-based scheme and institute a rolling auction to prevent unnecessarily contentious auctions. (Why should somebody have the chance to bid on something just because they find out that you’re bidding on it as well?) Johnson discussed the huge variety of domains that may become part of ENS in the future and closed by announcing the creation of the ENS Foundation.