Tari Protocol Discussion 26
On Thursday, the Tari community gathered to analyze different ways to make sure the high-performance second layer of the Tari network (The DAN) could leverage the high security of the base layer. Below is the TL;DR on Thursday’s conversation (full transcript included below):
One way to achieve a high security second layer is to require Validator Nodes to register themselves on the Base layer. This achieves:
- Sybil resistance (if we require a fee / deposit to be paid)
- A register of known VNs
At a high level, the registration process could look something like this:
- The Validator Node posts a MW transaction with a flag marking it as a VN registration TX.
- The tx contains a time-locked output for at least the registration fee amount that is paid back to the VN owner
- This time lock could be for say, 6 months
Another great thing about the refundable deposit model of registration is that the Active VN register is self-maintaining. You need to re-register every 6 months (ala SSL certificates) rather than requiring de-registration.
Join us for our next discussion on Freenode in #tari-dev.
Discussion times proposed by the Tari community:
Mondays: 6pm CAT (11am EST)
Thursdays: 11am CAT (4am EST)
To keep up with the latest Tari developments, you can follow the project on Twitter.
Transcript of Thursday’s discussion
4:00 AM <@cjs77> time for another dev chat :) 4:03 AM <simian_za> awesome, lets chat 4:09 AM <@cjs77> So if we imagine the base layer being a high trust, low performance layer; and the DAN being a high performance, lower trust layer; it makes sense to leverage the Base Layer where possible to effect high trust, high performance on the DAN. 4:10 AM <@cjs77> One way to do this is to require Validator Nodes to register themselves on the Base layer 4:11 AM <@cjs77> This achieves: 4:11 AM <@cjs77> i) Sybil resistance (if we require a fee / deposit to be paid) 4:11 AM <@cjs77> ii) A register of known VNs 4:14 AM <simian_za> Makes sense, could the deposit be used for anything else i.e. losing it could be a penalty for bad behaviour (determined via consensus)? 4:14 AM <simian_za> Or is punishment of this sort poor design? 4:14 AM <@cjs77> On a high level, I imagine registration going something like this: 4:14 AM <@cjs77> * The VN posts a MW transaction with a flag marking it as a VN registration TX. 4:14 AM <@cjs77> * The tx contains a time-locked output for at least the registration fee amount that is *paid back to the VN owner* 4:14 AM <@cjs77> * This time lock could be for say, 6 months 4:15 AM <@cjs77> simian_za: Great Q. I think the challenge is how to implement punishment in an elegant and simple way 4:15 AM → bordecraft joined (~email@example.com) 4:16 AM <@cjs77> I like Bob McElrath's tweet from a few weeks ago saying that any slashing / punishment mechanism can be gamed. I'm not sure I agree 100%, but I resonate with the sentiment. Rather let it "just work" through clever incentives 4:16 AM ⇐ bordecraft quit (~firstname.lastname@example.org) Client Quit 4:17 AM <Blackwolfsa> yip I agree with that, we should try and make it work without punishment 4:17 AM <simian_za> The challenge with any punishment mechanism is that it can be used maliciously. 4:17 AM <@cjs77> As it is, posting a refundable deposit via a time-locked output achieves Sybil resistance, which is a big step already 4:18 AM <simian_za> How will the fee be determined? 4:18 AM → bordecraft joined (~email@example.com) 4:19 AM <Blackwolfsa> Does it have to be timelocked? 4:19 AM <@cjs77> What I also love about the refundable deposit model is that the Active VN register is self-maintaining. You need to *re-register* every 6 months (ala SSL certificates) rather than requiring de-registration. 4:19 AM <@cjs77> blackwolfsa: ^^ is why time locks are highly desirable 4:19 AM <Blackwolfsa> As long as it exists, the node is"registered", if the node spends that utxo, the node is "de-registered" 4:20 AM <@cjs77> simian_za: Another good Q 4:20 AM <neonknight> The hash of the registration location could also be used as unique identifier for a VN 4:21 AM <Blackwolfsa> cjs77: for that to work we have to either check that the registration is newer than 6 months or something 4:22 AM <Blackwolfsa> a dormant node wont spend that as well. 4:22 AM <@cjs77> blackwolfsa: Having an auto-spend in 6 months guarantees that we get a check-in from a VN if they want to stay registered. If a VN operator loses interest and doesn't care about his deposit, it should auto-deregister, no? 4:23 AM <simian_za> How will an Auto-spend/Auto-refund work though? 4:23 AM <simian_za> will the transaction sit in the mempool? 4:24 AM <neonknight> Also not sure how to do an auto spend with mimblewimble 4:24 AM <@cjs77> yeah, it would have to sit in the mempool. 4:25 AM <Blackwolfsa> 6 months sitting in the mempool might does not seem very reliable. 4:25 AM <Blackwolfsa> I think its safer to just check how old his utxo is. 4:25 AM <@cjs77> So I reckon there would need to be 2 txs: One locking the output, and one that hangs around. 4:25 AM <@cjs77> >not very reliable 4:25 AM <@cjs77> perhaps - fair comment 4:25 AM <simian_za> So rather when an Asset Creator is looking for VN's he will ignore registrations that are older than 6 months 4:26 AM <Blackwolfsa> If we need to check how old his utxo is, we might as well remove the timelock 4:26 AM <simian_za> so a VN cannot use his old registration to take part in DAN activity 4:27 AM <Blackwolfsa> Yes, its not ideal, but its better than flooding the VN list with inactive VN's 4:27 AM <@cjs77> The timelock must stay -- otherwise it's cheap to run a VN, do something nasty, shut it down, get a refund; and repeat 4:27 AM <simian_za> Also a VN could register, get picked for a committee and then deregister and repeat 4:28 AM <simian_za> all with the same deposit amount 4:28 AM <@cjs77> The auto-refund is debateable; but the timelock is crucial for sybil resistance 4:28 AM <Blackwolfsa> ok makes sense 4:28 AM <neonknight> Agreed, timelock is important 4:30 AM <neonknight> If the deposit is high enough, inactive VNs wont forget to release the deposit 4:30 AM <@cjs77> Yeah, I guess we can't *force* auto-deregistration 4:31 AM <simian_za> you sort of can if you ignore old registrations for all the listing and validation operations 4:33 AM <@cjs77> So the question of how much to lock up. I don't know the answer, but some things to think about: 4:33 AM <@cjs77> * needs to be high enough to make Sybil attacks expensive 4:33 AM <@cjs77> * needs to be low enough to produce a "reasonable return" for VN operators running VNs as a business 4:33 AM <@cjs77> * high enough to encourage dormant VNs to claim the deposit ASAP 4:34 AM <simian_za> That is going to be a moving target as the value of Tari fluctuates 4:34 AM <@cjs77> sure 4:34 AM <simian_za> Can it be a function of the amount of Tari in circulation? 4:35 AM <simian_za> hmm but that doesn't take into account the market value 4:36 AM <neonknight> A function of mining reward could also be considered. 4:37 AM <Hansie> simian_za : Yes, and any direct link with fiat currency will be volatile 4:38 AM <Blackwolfsa> mining fee's should stay kinda in line with fiat 4:40 AM <Hansie> Yes, and therefor somewhat self regulated, but not so the block reward 4:45 AM <simian_za> So a function of fees does make sense. Though keeping track of the average fees in a decentralized manner is a challenge 4:46 AM <Hansie> cjs77: I am wondering about a registration term of say 6 months. Let's say I am an asset creator, looking to appoint VNs in a "permissionless" network appointed manner with some boundary conditions I specify for them. These could be some minimum collateral amount, some network credibility rating and "time-to-live" (i.e. time till auto de-registration). So I would like to know how many "terms" have been served, are they light 4:46 AM <Hansie> weight or heavy weight VNs and how long I can depend on them. Any ideas? 4:48 AM <Blackwolfsa> avg fee's should be easy to calc = (reward-block reward) / kernels 4:48 AM <Blackwolfsa> and we have some rolling limit of the avg between the last 10 blocks 4:50 AM <Hansie> Maybe the amount of collateral above a certain threshold could be self determined, thus market regulated. 4:52 AM <Hansie> Do we envisage a method whereby a VN can extend its registration window, for example renew it some time before it becomes invalid? 4:52 AM <@cjs77> Hansie: I think those are important questions, but possibly independent of the VN registration process? Personally I think VN metrics will probably be a second layer function 4:55 AM <Hansie> Yes, agreed not all for base layer. So maybe a mechanism to top up collateral, extend the registration window, and build up some sort of embedded track record? 4:58 AM <Blackwolfsa> extending could be easy, one reg-utxo -->> another reg-utxo 4:58 AM <Blackwolfsa> we could allow the properties like id etc to cary over 4:59 AM ⇐ bordecraft quit (~firstname.lastname@example.org) Ping timeout: 250 seconds 5:04 AM <Hansie> Yes, makes sense. So this could also take care of topping up the collateral, as the new Tx can combine the old collateral with a new input, or making it less. 5:07 AM <Hansie> So maybe the 'VN registration TX' could also employ a simple counter in the registration meta data that increases every time a re-registration is done without a lapse in active service? 5:16 AM ↔ oneiric_ nipped out 5:18 AM <mikethetike> > yeah, it would have to sit in the mempool 5:18 AM <mikethetike> I think it has to be on the blockchain, but locked up like a coinbase 5:18 AM <mikethetike> No autospend, although the VN could choose to create the autospend if they wished 5:19 AM <mikethetike> The registration can't actually be in the mempool, because then the locked up funds are not confirmed 5:19 AM <mikethetike> Unless I'm wrong 5:20 AM <mikethetike> or I have misunderstood what the registration tx is 5:21 AM — mikethetike reads previous messages 5:30 AM <neonknight> registration is on baselayer, but autospending needs to live in mempool