Transcript: Mainnet planning meeting

On Monday, 26 September, the Tari community held a meeting to discuss the idea of an "early" mainnet launch; i.e.
one that does not have a fully-fledged DAN in place.
The transcript of that discussion is below.
Welcome to the first online dev chat we've had in a while. And the first one on Discord
This meeting is relayed to IRC
and the transcript will be posted on our blog
[irc] /jedusor/ Receiving
Ok, a rough agenda is as follows:
As per the blog post Friday, we want to decide if launching mainnet without a fully-fledged DAN is the right decision.
If the decision is "launch", then
2a. Which features are included in mainnet
2b. What other things need to be done ahead of a mainnet launch
Based on this, the core devs can go and put together a provisional timeline based on the outcomes
Quick role call? Just make a noise to indicate your presence please
Present
Blackwolfsa
The vibe I have from the community is that there's a large majority that would support an early mainnet launch and continue to build the DAN with a live mainnet. So my assumption is that this motion is going to pass unless there's a lot of opposition now.
[irc] /jedusor/ Quick question
[irc] /jedusor/ Does anyone not work for Tari Labs?
You mean in this meeting?
So far, the majority do work for TL. But not everyone
In the broader community, esp telegram, I'd guess <50% are TL
TL here
I like the early mainnet launch theme, especially if it can have the basic hooks to support the DAN later on.
[mattermost] /leet/ 👌
For those who haven't been following t home, our current Esme testnet has the following features:
Mimblewimble core
Tariscript
Covenants
One-sided payments (i.e. non-interactive MW payments)
Burn transactions
So we already have a pretty rich set of features that expands beyond vanilla MW; so the thinking is that there is a solid justification for launching with this set as we continue to work on the DAN.
Blackwolfsa
It should be noted we have removed the ability to do cut-through of transactions in the mempool
The proposed switch from side-chains to Cerberus is also a consideration.
Blackwolfsa
Thats something thats in MW core, we had to remove to enable support for TariScript
The pros of launching now would be that we get an established base of miners and other developers can start building on it, the cons may be that we don't offer enough of a difference from Beam, Grin and other MW coins to be relevant
Another Esme testnet feature worth mentioning:
Stealth addresses for one-sided payments
+1. Stealth addresses. Thanks @pluto
[irc] /jedusor/ I thought there was no point to launching mainnet without the DAN ready?
I said it at the time, but cut through only really comes into effect if there is zero conf spends
We're rethinking that point Jeduser
Hence this discussion
so from an audit point of view, it makes sense IMO to separate the base layer and dan layer
The #1 comment in the community is "wen mainnet?". Are we being silly in holding out, maybe for another 2 years, while the DAN gets fully built out?
it's also less risky to release smaller pieces
The Esme testnet already offers features that will enable some types of smart contracts basically out of the box, for example atomic swaps with Bitcoin and multi-party m-of-n spending scripts, also not mentioning what covenants can be used for.
MY main objection to launching early has been the need to lug legacy code around for all time if there are ever big changes in philosophy; but I'm now reasonably comfortable that the interfaces to the DAN (like node registration transactions etc) are fairly stable, so even something like a switch from SCs to Cerberus doesn't affect the base layer much at all.
So, if launch without the DAN, it'll be add in some point of the future, right? If yes, will happen a migration to the DAN? How it will work?
The DAN is a 2nd layer.
But yes, Tari's main selling point is the DAN – so that's the main focus post mainnet
Thinking about the devs that can start to create something on it (in a "early launch") , they will need to rewrite stuffs to be compatible with a 2nd layer, I imagine. I think it can be a friction point with the community.
Imaging that happen a launch without the DAN, in the future when it be launched, the dev community that are developing stuffs arounds the Tari base layer probably will start to migrate to the new 2nd layer. At this moment, I imagine that some things developed will need to be rewritten to run in the 2nd layer using all those new features. If it's right, I think it can be a frustrating point to some devs that build things around Tari. Of course if the launch happens directly with a 2nd layer, probably the devs will not need to rewrite apps in the future, avoid some "friction" with the community.
I argue that putting a peg in the ground (i.e. the base layer) makes it more stable for developers
just cross-posting a comment from @bibimbap on Telegram:
"Actually I just read the article and it's pretty cool
I was worried the merge mining with monero was going away but this is only for the second layer
"The broad consensus among the core developers is that we should launch the base layer without a fully functional DAN, and bring the DAN online in a smooth and orderly fashion." This is also good
also leaves a big catalyst for the future"
DAN upgrade doesn't require a hardfork, correct?
Ok, I understand your point now, thanks.
So the core devs (and anyone else) publish RFCs regularly explaining the thinking around the DAN development. So on one hand, anyone in the community can see the general dev direction and plan and/or comment accordingly.
Secondly, the L1 smart contract capabilities are limited compared to what the DAN will offer. That said, it's already comparable to (and because of covenants even superioir to in some cases) what you could do on Bitcoin.
But these features don't change. So if you went and built something on L1, it would still work post-DAN, but it would be like still trying to navigate your horse and buggy on a highway full of Porsches
Diving into some technical details here, but the interaction between the base layer and DAN layer would require the following:
The base layer is a registry of VNs
Tari can be pegged into the second layer via the burn mechanic
Epochs and rules are managed via the base layer
stringhandler — Today at 11:41 AM
it would require a hard fork to enforce some rules, but hard forks are part of adding anything to the network
there will always be hardfork
It will; but maybe not for the reason your question alludes to. Because Tari is not afraid of hardforks (similar to Monero), there hasn't been much effort in putting a soft-fork upgrade mechanism in place.
[mattermost] /pluto/ 👌
I am happy with these features, however I would suggest maybe restricting the op_codes for TariScript and Covenants initially and maybe hardfork to enable them on a regular (maybe 4 or 8 weeks) schedule
So let's move onto topic 2.
There have been some very good questions around the topic of an early launch, but not any vehement opposition.
i.e. progressively allow more op_codes
So let's say we go ahead with an early launch. To decide on how early that might be, we need to draw up a TODO list of things that must happen before we could safely launch
I've gone ahead and prepped a list in anticipation of this call, but I might have missed a few things. So here's my provisional list:
One-sided payments code is stable
Burns are stable
Validator node registration code is stable
Emission curve is finalised and ratified
Stagenet code freeze.
Audits
Identify code to be audited
Identify Audit partner
Book, fund, and perform audits
Resolve all findings from audits
VN reg is the only point there I'm a little hesitant on
There are also a bunch of nice-to-haves:
RFCs up to date
Aurora prepped for mainnet
Launchpad ready for aminnet
TLU refresh
the others are stable and unlikely to change
We could have VN reg behind a feature flag, or remove as a requirement
How will it work ? If we allow that feature, users can register a VN before DAN and would this allow them to 'reserve' VNs in anticipation to the DAN ?
Good question 🙂 It depends
For the audit items, I think some areas that need audits specifically are:
TariScript and the balance checks
Covenants
The proof of work (specifically merge mining) implementations
There's no value in registering before the DAN is close to being live
for stagenet code freeze, what stops us from doing that now?
VN registration happens multiple times so you could register one but you would need to continue paying to re-register it. Which seems like a wasteful endeavour. So I think the answer is yes you could, but like… why?
Freezing — audit results notwithstanding?
I think we'll need to tag a commit for the audits
it'll depend on the audit firm's methodology
I think what I'm trying to guage here is more "is this the list of things we need to do" vs the specifics of those things
so what have we decided so far?
Definitely, it is a wasteful endeavour. I think if we launch this feature right away we should be explicit that there is no point in using it, so that users are not mislead
Features to include:
Stealth addresses – YES
One-sided payments – YES
DAN interfaces (template and VN registration) – MAYBE
*Burns are also a DAN interface
From a base-layer mainnet perspective, is this a complete list?
base-layer NODE perspective, I should say
Pruned mode and archival mode
There's also console wallet, aurora, localhost:8881/, TLU, RFCs that are important but not related to the immutable genesis block directly
But we'd def include the core wallet code in the audit process anyway
I am happy with that list
with DAN interfaces being – NOT AT THIS TIME
Ok, let's conclude the meeting there.
The next step would be to take this list and map out realistic timelines for when these might be complete
Since Tari Labs will be paying for the audits, we'll leave it to them to map out that process
Thank you everybody that attended