Tari Protocol Discussion 12
Monday’s Tari protocol architecture discussion was all about the base layer modules of Tari’s architecture proposal. Specifically, a few questions needed to be answered, as the above architecture proposal is only a rough draft. Questions like:
- Are the main moving parts of the base layer covered in the architecture proposal?
- Should the design layout for the code be grouped by function or by software stack?
- Does the Tari protocol architecture align with the folder structure proposal?
- Are Tari’s base layer modules sufficiently decoupled from each other?
The full discussion was one of the most vibrant Tari community discussions to date, and set the stage for a Thursday discussion on 2nd layer protocol architecture.
Join us for our next discussion on Freenode in #tari-dev. Discussion times proposed by the Tari community:
Mondays: 8pm CAT (1pm EST)
Thursdays: 11am CAT (4am EST)
To keep up with the latest Tari developments, you can follow the project on Twitter.
Transcript of Monday’s discussion
10:01 AM <@cjs77> Hey all 10:01 AM <simian_za> Hiya 10:02 AM <neonknight> Hello.. 10:02 AM <@cjs77> I thought we’d discuss the project layout tonight 10:02 AM <Hansie> Hi there 10:02 AM <Hansie> Sounds interesting yes 10:03 AM <@cjs77> ref: https://github.com/tari-project/tari/pull/2 10:04 AM <@cjs77> with context: https://github.com/tari-project/RFC/tree/master/proposals 10:04 AM <@cjs77> In particular the high-level and base-layer proposals 10:04 AM <tk___> hey 10:05 AM <@cjs77> mikethetike had a suggestion: 10:05 AM <@cjs77> > I would have put all the base_layer folders in the root, and just had the digital_assets_layer as digital_assets 10:06 AM <stanimal> Hey everyone 10:06 AM <@cjs77> For those who don’t RTFM, here’s a summary: 10:06 AM <@cjs77> > The code follows a domain-driven design layout, with top-level folders falling into infrastructure, domain, or application layers. 10:06 AM <@cjs77> The infrastructure folder contains code that is not Tari-specific. It holds the following crates: 10:06 AM <@cjs77> comms: The networking and messaging subsystem 10:06 AM <@cjs77> crypto: All cryptographic services, including a Curve25519 implementation 10:06 AM <@cjs77> storage: Data persistence services, including LMDB 10:06 AM <@cjs77> The base_layer is a domain-level folder and contains: 10:06 AM <@cjs77> core: common classes and traits, such as Transactions and Blocks 10:06 AM <@cjs77> blockchain: The Tari consensus code 10:06 AM <@cjs77> mempool: The unconfirmed transaction pool implementation 10:06 AM <@cjs77> mining: The merge-mining modules 10:06 AM <@cjs77> p2p: The block and transaction propagation module 10:06 AM <@cjs77> api: interfaces for clients and wallets to interact with the base layer components 10:06 AM <@cjs77> The digital_assets_layer is a domain-level folder contains code related to the management of native Tari digital assets. Substructure TBD. 10:06 AM <@cjs77> It’s envisaged that at least the following applications are built on top of the domain layer libraries: 10:06 AM <@cjs77> A standalone miner (tari_miner) 10:06 AM <@cjs77> A pool miner (tari_pool_miner) 10:06 AM <@cjs77> A CLI wallet for the Tari cryptocurrency (cli_wallet) 10:06 AM <@cjs77> A full node executable (tari_basenode) 10:07 AM <simian_za> wont the digital assets layer also have its own p2p and api crates? If so then it would make sense to keep the current structure 10:08 AM <@cjs77> https://www.irccloud.com/pastebin/I5ZeLnAX/ 10:08 AM <@cjs77> That’s better :) 10:08 AM <@cjs77> simian_za: that’s why I ultimately proposed the current structure 10:09 AM <@cjs77> There will be name clashes since we’re not just building a mimblewimble implem,entation, but a digital assets network as well 10:10 AM <simian_za> In terms of the applications I feel like the tari_miner and tari_pool_miner will be more tightly coupled 10:10 AM <Blackwolfsa> this makes more since, putting the da layer and base layer seperate 10:11 AM <Hansie> Yip, I would go with functional groupings rather than software stack groupings 10:12 AM <Hansie> We may potentially have multiple consensus algorithms/schemes/protocols, where would they live? Infrastructure? 10:13 AM <simian_za> if they relate to the base-layer in /base_layer/blockchain and for the digital_assets_layer in a folder related to consensus? 10:14 AM <@cjs77> If they’re blockchain agnostic, then they should go in infrastructure; with a suitable abstraction layer; If they use blockchain language, then they’re domain layer 10:16 AM <@cjs77> A more clearcut example is a datastore like LMDB. It’s infra. A websocket library is infra. I’d argue that ECC libraries are also infra 10:17 AM <Hansie> I think it would potentially be applicable to both layers, but more so the 2nd layer 10:17 AM <Hansie> Plug-gable consensus perhaps… 10:18 AM <simian_za> my gut says consensus algorithms would be fairly closely tied to their respective layers? But I suppose we might get really good at writing very modular code 10:18 AM <neonknight> The “Blockchain” section of “infrastructure” already says “The Tari consensus code”, might work well there. 10:19 AM <@cjs77> yeah it depends what you mean by consensus algo. Nakamoto consensus is pretty tightly coupled to the base layer :) 10:19 AM <Blackwolfsa> but going by the design, the consensus on the base and second layer would be fundamentally different 10:21 AM <simian_za> what else would be in the base_layer/blockchain folder? the datastructures to store the blockchain, all the merkle proofs to determine the chains validity and? 10:21 AM <Hansie> We may have some consensus re-use if there is a case where consensus is needed on the base layer for some arbitration on the 2nd layer? 10:22 AM <simian_za> I feel like that consensus code would like in the second layer crates and then be pulled into the base_layer from there 10:22 AM <simian_za> like = live 10:23 AM <@cjs77> In any event, with the folder structure ±locked in, and given the alignment with the high-level architecture, we can start to map out some milestones and initial tickets for the independent modules 10:23 AM <@cjs77> and then you guys can go and play with some code :) 10:24 AM <simian_za> woop woop, finally! 10:24 AM <neonknight> That will be a good day 10:24 AM <Hansie> @simian_za, “what else would be in the base_layer/blockchain folder?” maybe something to do with emission schedule, token management, inflation, block times, etc. 10:28 AM <simian_za> 👌 10:28 AM <Hansie> Where ‘smart contracts’, ‘script-less scripts’? 10:29 AM <simian_za> hmm that’s a good question. Those will be coupled to both the base-layer and second layer 10:29 AM <Blackwolfsa> I would probably think more base layer 10:31 AM <Hansie> Also, perhaps an asset_management application for the asset issuer? 10:32 AM <simian_za> perhaps just a GUI wallet that can handle interaction with the base and second layers? 10:32 AM <mikethetike> I think most of the other coins build that into the default wallet 10:35 AM <Hansie> I feel uneasy about that @mikethetike, adding things in one application with very little in common, or am I mistaken? 10:36 AM <simian_za> traditionally the wallet application is where the client functionality lives 10:36 AM <mikethetike> The wallet functionality is really small 10:36 AM <mikethetike> in most coins 10:36 AM <@cjs77> scriptless scripts are split between domain and infra. e.g. a generic signature aggregation scheme (e.g. MuSig) falls under infra, but an atomic swap would be built on those primitives in the domain layer 10:36 AM <Blackwolfsa> Both would likely be written as a small library, to implement both would be trivial 10:37 AM <@cjs77> a wallet is an executable though, and shouldn’t be in the libraries 10:37 AM <Blackwolfsa> yes, but I would believe most of the functionality should be written as libraries 10:37 AM <@cjs77> yeah the API will be a library 10:38 AM <@cjs77> That makes it easy to write a CLI wallet and a GUI wallet without repeating any code 10:39 AM <Hansie> @cjs77, you lost me with ‘domain layer’, is that in the folder structure? Or should I read between the lines… 10:41 AM <@cjs77> Domain layers are layers that contain the business language & logic. For Tari there are basically 2 domain layers: The base_layer and digital_asset_layer. They’re broadly independent, hence they’re separate, but they’re both built using domain language terms like `Block`, `Transaction`, `TariAmount` etc. Does that make sense? 10:42 AM <Hansie> Perfect thanks :-) 10:45 AM <Hansie> So i.t.o. applications, if we have a ‘tari_basenode’ should we have a ‘tari_validator_node’? 10:45 AM <@cjs77> blackwolfsa: re: If I infer where you were getting at with your comment about applications — if we do this properly, the applications are mostly just wiring things up, right? I mean the CLI app code shouldn’t be more than a few hundred lines (read config; get input; relay to API, return results) 10:45 AM <@cjs77> Hansie: yup 10:45 AM <@cjs77> but we haven’t really discussed what the 2nd layer looks like yet 10:45 AM <Blackwolfsa> yes, correct 10:46 AM <Hansie> Good 10:46 AM <@cjs77> Maybe we should start that conversatoin on Thurs 10:47 AM <Hansie> Great idea 10:51 AM <simian_za> It is a nice context to start thinking about the components we need to build 10:51 AM <@cjs77> +1 10:55 AM <@cjs77> Cool, so I’ll merge that PR in; and then there’s a small PR for some crypto primitives that sort of illustrate my thinking around abstraction, documentation and testing, which everyone is welcome to comment on 10:56 AM <Hansie> Cool 10:56 AM <simian_za> 👍