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 the 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.
Below is the full transcript of Monday’s discussion.
BEGINNING OF 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> 👍
