Vipnode: Progress Update #3
Overall: Feature complete for the v2 milestone, approaching the v2.0 release.
What is Vipnode? Vipnode is an implementation of economic incentives for running Ethereum full nodes who serve light clients. More context here.
We’re approaching a stable release! You can try the latest demo binary release here: https://github.com/vipnode/vipnode/releases
Once we’re done with the pre-releases, the plan is to dive straight from 0.2.x into v2.0. It’s a weird versioning strategy but I’ve been referring to the original MVP implementation as “v1” and the current roadmap as “v2” so that’s what we’re doing.
There is still a lot of love needed for all the pieces, but I’m comfortable to say that we’ve exceeding the deliverables of the “v2” milestone (which was the Ethereum Foundation grant milestone). 🎊
Payments: A Walkthrough
The big theme of this release is integrating payments. Recall that the premise of v2 is that full node hosts can earn money for servicing light clients, and light clients will be paying for the privilege.
The implementation of the payment mechanism is generalized. The demo example is using a smart contract, but it could really be anything —imaginary internet points, tokens, or even credit card! Adding another payment mechanism can be done by specifying your own settlement handlers for payment.PaymentService or implementing a custom balance.Manager provider.
The rest of this post will focus on the sample payment mechanism we’re shipping with: The smart contract and DApp solution.
When you run the vipnode binary as a client, it looks like this:
Each pool will be able to supply their own welcome message with rules and instructions for managing your node’s balance. The demo pool allows you to accrue a negative balance for now, so you won’t get disconnected even if you’re unregistered.
If you open the link in the alert, you’ll land on the DApp (make sure to use a web3-enabled browser).
If you clicked the link from your
vipnode client alert prompt, the Add Node input will be pre-filled, so all you have to do is mash the button.
As a client, your balance will decrease with usage (maybe we need a ‘Total’ field that adds the Balance to the Deposit). A less generous pool will kick you once your negative balance exceeds your deposit amount.
If you’re done with this pool and want to cash out, you can Request Withdraw which will trigger the pool to queue up a withdraw transaction. If the pool disappears for more than a week, you can force a settlement on-chain and get your money that way.
The host experience is similar to the client, except you need to provide a public enode string (which includes your IP address and port for now) and a payout address.
Once the host is connected, the pool will start routing clients to your host. As clients connect, the host’s balance will grow on every minute update.
When the host wants to cash out, they can go to the same DApp and use the same Request Withdraw process that the client can use. For the most part, internally, clients and hosts are symmetric. A user can be both a host and a client at different times, and contribute to or draw from the same balance.
“Boy, this seems a bit complicated for The Average User, no?”
Perhaps, but that doesn’t matter because your favorite wallet can integrate all of this natively and the user doesn’t need to see any of it!
Imagine: You fire up your local neighborhood wallet, and you might see a prompt: “Having trouble connecting. Do you want to deposit $10 to use with a paid provider?” The wallet can do the rest behind the scenes.
The command-line client above is a proof of concept that can totally be used today! Underneath, there is a simple API that any wallet can implement, and I’m talking with several teams about moving forward with integration.
- Recent focus was on adding importing features, so now it’s time to clean up and polish. For example: Make the payment settings configurable (they’re currently hardcoded). Host connecting shouldn’t require as many parameters (we can derive much of it). Lots of TODOs in general.
- I’m putting together an Ethereum Magicians Working Group for coordinating between wallet stakeholders who need a minimal-resource client support like light clients: https://ethereum-magicians.org/t/forming-a-ring-constrained-resource-clients/1944
- Getting an integration with an actual wallet is a higher priority now in general.
That’s all for now. Give the latest demo a try and let me know what you think. I’m travelling the next couple of weeks, so please be patient with replies.
Sign up to the Vipnode Newsletter for future updates.