Auryn Macmillan I Modularity Matters I Gnosis I Pragma Sydney 2024

[Music] all right with that we are ready for our next speaker and for this next talk I want to bring on Orin who is the founder of Nosa Guild to talk about why modularity matters and how you can take advantage of all the upcoming things in the world of modular blockchains and just architecture so with that please welcome Orin on stage and hope you enjoy how to think about [Applause] modularity all righty testing all right hey guys uh so in 2012 I was riding the bench for an mbll team just down the road from here uh the wooling gong Hawks I was the fourth string big behind a handful of veterans uh we're down 15 points in the third quarter against the league leading Perth Wildcats uh they're on this five-game winning streak super hot um and our starting center Larry Davidson goes down with an ankle injury our coach uh Gordy McLoud looks down the end of the bench and calls my name uh and so what turned out to be one of the uh better games of my short NBL career uh I managed to slow down Perth Star Center just enough for us to fight back and Come Away with this really huge upset win uh so hey guys I'm aurin I've been contributing to the ethereum ecosystem for around a decade for a variety of different uh roles in a variety of different organizations most recently I'm the co-founder of Nosa Guild we build a whole bunch of uh modular tooling for the ethereum ecosystem um and now I bring bring up the the kind of basketball backstory here just to give a bit of context on how and why I value modularity so highly when it comes to system design in basketball and most team sports having a variety of different players available to plug in into various positions in response to the current situation uh the opposition time and score injuries uh where you're at in the season all this good stuff uh it's really critical to creating resilient teams that can consistently perform well um teams that rely too heavily on one or two specific players or strategies become as fragile as those specific players or strategies and the best teams are adaptable they can adapt to the current situation by modifying their composition or their strategies um in short by being modular so basketball teams are these Dynamic systems uh and these same principles apply to just about any dynamic system from a sports team to a blockchain and everything everything in between slide um so what is modularity I simply put modularity is this design principle uh of implementing systems as combinations of separate components each serving this distinct function uh in a greater system these components or modules can be independently developed uh replaced modified without necessarily impacting the rest of the system uh we see lots of gestures towards modularity all around us the most classic example being the humble Lego brick uh but modularity is examplified in everything from Minecraft to Ikea furniture to music synthesizers uh and in technology modularity allows for more robust more adaptable systems partly why Unix is such a stable and secure operating system is because of its insistence on these modular design principles allowing users to add remove uh and create arbitary chains of components based on their specific needs uh similarly WordPress extends functionality through modular plugins and themes that all operate on the same kind of core site uh and the software development platform Docker puts applications into modular containers uh making them portable and easy to manage across different computer environments so to helped think through this a little bit more uh it's useful to compare modular systems to more monolithic systems where all of the components are tightly integrated uh you can think of these monolithic systems as single indivisible units where changing one aspect often means uh significant changes to the entire system the uh this design might simplify the initial development and deployment but it can quickly become cumbersome as systems grow and evolve in response to changing user needs uh and environmental conditions for example up updating a single feature in a monolithic system uh can often require redeploying the entire system uh which really complicates maintenance and introduces huge amounts of risk uh this is Akin using the basketball analogy here akin to a a one-on-one basketball team so in in a one1 scenario the the team's ability to respond to any given situation or adversity is entirely dependent on this one player no Personnel adjustments uh based on time and score and opposition no capacity to deal with injuries or fail trouble uh ultimately a fragile system a system as fragile as that one player modular designs address this kind of fragility by separating stages of a process into discrete components uh often with layers of redundancy but modular designs are not all made equal uh an important and really often overlooked uh distinction should be made between closed and open modularity so by closed modularity I mean systems where module production is either permissioned or modules are inseverable from some given core component um could I take this module and plug it into a different core component uh the answer is no there's a good chance that this is a closed modular system that exists in service of some kind of Monopoly a a classic example is uh two-sided marketplaces like Amazon the Apple App Store Airbnb they offer this form of modularity where sellers can uh sellers consumers developers can freely participate on either side of the marketplace by offering or consuming products uh and services but their core components are not modular uh an app developed for iOS cannot easily be run on non-apple devices uh for example and you can't easily Port your Airbnb listing and reputation into another booking platform um the explicit justification for this closer sorry there we go okay so the explicit justification for this kind of closed modularity is generally around ensuring uh a degree of reliability and uniform performance across uh across all modules guaranteeing a baseline user experience um Apple's ecosystem is again a really classic example of this uh where hardware and software are really tightly controlled to ensure this seamless integration and user experience but this comes at a really significant cost to both users and developers uh ecosystems of closed modularity more often than not are used in service of cornering some Market retaining users and ultimately extracting value from them uh this is achieved by making modular components that are overly dependent on One Core component or vendor uh that cannot easily be replaced uh we can see this distinction with Lego and Ikea that I mentioned earlier both of which are really classic examples of modular systems but are ultimately closed due to their uh their patents and complex licensing structures which inhibit third party participation and Innovation and limit user choice and control so closed modularity locks users into a particular set of products or Services making it difficult to switch providers or choose Alternatives uh without significant costs to uh users without significant inconvenience and uh essentially poses this existential risk to Applications deployed on top uh and to organizations kind of dependent on those applications open modularity on the other hand uh Embraces a much broader approach to modular design where module production is permissionless and modules are interoperable across a variet across various core products or protocols the key key distinction being whether or not there is a privileged component or system that uh cannot be easily replaced by an alternate implementation uh open modular systems are largely based on principles of interoperability and decentralization uh and in these systems modules are designed to be compatible across different systems networks uh and every component should be replaceable fostering this more inclusive and Equitable developer environment and giving users uh greater choice of of where they interact of the the trust assumptions they make uh and ultimately uh more control over uh their property uh and their uh their interactions with these systems uh so while there's many benefits from open modular designs I'd like to highlight five that I think are especially important in the context of web 3 uh so interoperability in an open modular system ensures that different modules can and work seamlessly together even if they're developed by different teams this allows system designers to integrate the set of modules that work best for their needs regardless of the team that developed them uh fostering a te technologically diverse environment uh using the basketball analogy do the players have a Common Language and understanding of the team strategies such that a new addition to the roster could easily be slotted in uh when you're designing systems you can ask yourself if if your chosen component is using standardized inputs and providing standardized outputs so that it can easily be replaced with similar components uh also conforming to those same standards uh next up is uh permissionless Innovation so in an open modu system Engineers have the freedom to choose uh to create and distribute new modules uh and to compose modules into novel systems uh without seeking permission um this open design results in know really developer friendly atmosphere and creates a space for healthy competition which ultimately leads to better products and services as teams individuals uh improve on their offerings and push boundaries for what's possible uh using the basketball analogy imagine if only players trained by a specific school or coaches with a specific accreditation allowed to coach uh actually the the lad is kind of true in a bunch of leagues the former not so much um but when you're designing systems you can ask whether you need someone's permission to build a component or to compose a system um as a good kind of litus test for whether it's uh again whether it's this kind of open modular system next piece that I think is really critical uh in web 3 is resiliency uh so due to their tendency to spawn and support redundancy uh diverse implementations of the same function uh open modular systems tend to be more resilient with stronger security properties than their closed counterparts uh this quality is particularly valuable for consensus based systems multiple client implementations along with a healthy balance of those clients being run by nodes minimizes the potential damage that could be done uh by a bug in any specific implementation using the basketball analogy what happens if a given player fils out is there someone else who's available to immediately pick up the slack someone else that be can can be uh slotted into that role and so when you're designing systems here ask yourself what happens if there's a critical bug in the implementation of this component uh can another implementation be slotted in to pick up the slack uh can it be kind of isolated from the rest of the system um all so portability and replaceability every component in an open modular system should be portable and replaceable so forcing uh component implementations to compete on Merit rather than on privileged status in the system uh this reduces switching costs for users and limits their exposure to the fragility of Any Given uh implementation uh and the the fragility of Any Given organization maintaining an implementation using again the basketball analogy what happens if a given player does a season engine any injury rolls an ankle tears an ACL or something and is out for the year do we have a viable replacement can we replace that player um when we're designing systems we can ask ourselves what happens if the company maintaining a given component in our system ceases operation can we viably replace that uh component with another implementation and will it impose significant switching costs what happens if uh the the people maintaining a given component decide to deny us access to that component can we reasonably replace it or migrate from it uh without impacting the system uh and finally flexibility and adaptability the the previous benefits allow networks not only to evolve by integrating new modules but often to maintain a certain level of liveness throughout that process and because that same mechanism can support both diverse and evolving needs a large range of users can be supported for a much longer period of time uh this enables networks to continue to operate efficiently while still being able to uh respond swiftly and seamlessly to market conditions and cultural changes um offering Dynamic components that often times uh that are often times missing in closed modular systems using the basketball analogy we can think about a team uh how a team responds when a new rule is implemented uh the the three-point lines move back a legal defense is added in um refs start policing more strictly flops or something like this uh can the players handle that change uh does it require altering the the rotation altering the Personnel on the team uh doesn't require a complete overhaul of the Personnel um and when we're designing systems we can can ask ourselves uh how would this system respond to an incremental Improvement in some of the underlying technology uh could the new technology be easily incorporated into the system uh or would it require essentially a rewrite of the entire system in a modular uh of open modular scenario we can ideally replace just a given module slot it back into the system and and maintain liveness whereas more monolithic and more closed designs May require a um significant overhaul of an entire system um in web 3 we see a bunch of these uh Concepts play out in their networks and ecosystems that we engage in uh the ethereum ecosystem has made this really conscious shift towards ever greater modularity over the last close to a decade decade yeah um and we you see uh See this clearly at the consensus and execution layers um where e theem is explicitly designed to support multiple client implementations uh across its Network so given sufficient client diversity this design enhances ethereum's resilience uh tremendously as limiting the Network's exposure to potential bugs in any of its various client implementations u means that it's uh it's much less fragile uh ethereum is only becoming more modular uh while all blockchains used to put their execution uh settlements uh data publication consensus layers into one single component ethereum's moved in this direction of kind of separating consensus as and execution into distinct components and then making this larger step uh towards rollup Centric scaling and uh a a whole bunch of other applications coming online to modularize the other kind of critical components of building uh blockchain applications things like data availability layers uh all in a way that has not required permission from any given authority to enable uh which is this really kind of critical marker for this open modular system uh so with multiple imp implementations uh and separation of core components ethereum provides a nice framework for Innovation uh and adaptation in modularity uh in fact we are currently witnessing this wild influx of of rollups app specific chains VMS and other modular uh components as part of this wider expansion into modular blockchains a whole host of projects uh igen Laya Celestia optimism arbitrum scroll C sync Tao risk zero hashy um connects uh helping to increase uh the sophistication and diversity of ethereum's modular components uh allowing users to and Builders to construct systems from a wide variety of different components uh tailoring and tuning the the functionality cost and Trust assumptions that make sense for their application and for their use case um another example of modularity in the wild uh is much of the infrastructure that we've built at nosis skill zodiac is this really uh great example of an open modular standard for accounts um it provides a standard interface for composable and interoperable modular account tooling where most previous programmable account implementations uh were built as this kind of Monolithic and somewhat closed system zodiac decouples authentication and execution logic uh enabling this flexible module based control of pro programmable accounts um multiple control mechanisms in parallel cross-chain accounts and the ability for users to switch between tools and Frameworks with really minimal friction uh our modules are most well known as part of the safe ecosystem but we very deliberately designed it in such a way to be uh essentially agnostic to what the core account standard is so as long as it conforms to this I Avatar interface uh it can be applied to to any programmable account uh and so because of zodiac open design many organizations have created their own zodiac modules on top uh and and started to develop this really uh phenomenal ecosystem of of modules um plugging into this uh this kind of modular account core uh this is includes connect Uma clarus Pala Dow house and and a whole bunch of others uh so one last point I wanted to highlight here is the really critical role that standards play in uh in this kind of open modularity um uh space uh standard processes like uh the itf's RFC PR process ethereum's ERC uh process um have this really critical role in enabling uh permissionless Innovation Open Standards uh allow for a diverse set of inputs and factoring in of many many different real and potential use cases uh and applications that simply can't be considered when standards uh or implementations are designed in isolation so open standards are this really critical component to enabling the kind of modular uh open modular systems that I think are really valuable to the web3 space um so just in closing here as we look towards the future um we're clearly heading into an era of Greater modularity uh at least in the ethereum ecosystem and so I've been reflecting a lot on the Unix philosophy uh that the strength of a system is not just in the robustness of its individual programs but in their ability to combine with other programs to build complex systems from simple modular components uh we have an opportunity to embrace this philosophy in web 3 uh by creating tools that are not only efficient in isolation but are fundamentally designed to operate in a variety of context and systems enhancing the functionality uh and therefore the overall social and cultural impact that they can have uh this approach encourages us to to rethink how we build and integrate technology into our lives uh instead of adding an option or a feature in response to every need we can consider where that need comes from and perhaps eliminate the need for an option in the first place by breaking up up breaking our process down into uh modular components in this way components can act more like filters transforming inputs uh into outputs that feed into the next phase of a process allowing for efficient and adaptable systems uh but most uh perhaps most exciting is that open modularity lays the foundation for systems to evolve uh evolve over time based on demands because the because of their permissionless and decentralized nature modular worlds become uh will become even more pluralistic and even more resilient as more Engineers Builders and users engage with them um uh engage and contribute to them uh just as ecosystems with greater biodiversity have a greater chance of flourishing Technical Systems that adopt open modularity uh will be better equipped to handle future challenges uh so as we continue to build an experiment with these novel Technologies open modularity should serve as this uh not only as a design strategy but as this guiding star that Fosters diversity adaptability and sustainability uh the broad I guess take-home message uh here is that when we're designing and choosing systems there's a host of good reasons to prefer open modular systems even if they sometimes require a little bit more upfront uh effort to implement uh or don't have quite as pretty of a user experience uh or or shiny of a a user interface um for the folks here participating in the hackathon tomorrow um I encourage you to think both about uh how the system you're designing could be built with existing modular components uh and also to be wary of building a top systems that appear PE modular at the surface but are ultimately closed modular systems uh locking you into uh kind restricting your future design choices um that's it for the talk thanks for joining me to chat uh about some modularity matters uh I'm aurin McMillan on Twitter Orin at no.org via email be around for the rest of the week uh and then for the hackathon over the weekend if you want to connect come find me happy to chat [Applause]