"An Introduction to Logos, the future of Freedom" by Jarrad Hope // ECC#2 - Buenos Aires 2025
Ethereum Cypherpunk Congress·Fri, Jan 9, 2026, 12:00 AM
Speaker
Jarrad Hope here introduces Logos Network and their aims. Ethereum Cypherpunk Congress by Web3Privacy Now is the world's largest cypherpunk and human rights event. 4500 people gathering in Buenos Aires to celebrate privacy with internet freedom leaders like Richard Stallman, Vitalik Buterin, Roger Dingledine, and Eva Galperin. Join us in building a free internet for all. Website: https://web3privacy.info/ Congress site: https://congress.web3privacy.info/
Transcript
[applause] All right, cool. Hi, thank you for making it to the end. I'm sure you're tired. I'm tired. Uh, but it's been a fantastic day.
Um, I'm here to talk to you about, uh, Logos. This is going to be a very, it's kind of a weird talk for me. It's a little bit of a high level introduction. Um, and I would normally talk about political philosophy or like uh my internal motivations. Um, if you're not familiar with any of my talks, you know, there's some QR codes to some of those.
I I think for this crowd, like you're already here, so you kind of already internally understand why privacy matters and these sort of things. But you might be interested in uh corruption KYC and the cost of compliance and how this sort of went handinhand with the Patriot Act when the three towers were demolished. Um anyway, uh so show a hand who can recognize all of these logos. Okay. All right.
Oh, yeah. Yeah, [laughter] I that's expected. Um for for the rest, uh that's no surprise. Uh basically like you might be familiar with the onion to um so like on the the sides there there's to and there's the ITP network. Um the things that look like little bunny rabbits.
uh they are uh freenets and hyphenets uh and uh the one with bullhorns is new nets right and so like these are not like tour and ITP you you understand probably like they're anonymizing networks they allow you to basically have censorship resistant uh communication uh while being anonymized in doing so both in sender and receiver unlinkability um but like freenets and new nets uh were kind of more ambitious than just doing anonymizing networks. Uh they envisioned a civilian internet. Uh they were very concerned about the sort of uh digital intermediation that is currently happening uh through all of these sort of big tech platforms are doing like this sort of neo feudalism. Uh and they worked on creating this sort of decentralized technology stack that allows you to publish sites outside of like a typical client server model. Um and uh the middle one there that's Tribler.
Um Trib is a Bit Torrent client, right? It is fully peerto-peer. Uh they claim they have one of the f fastest peer-to-peer search um for that. So you can find content with it and they use onion routing as well to protect you while you're torrenting. Um that's a university project out of Del University in the Netherlands.
Um, but like this all of these projects are effectively like 20 years old, right? Um, and like this idea like there's so much we can still learn from those that I just don't really see actually happening in the space today and like we should really be continuing uh that on. In fact, one of the reasons I fell in love with Athereum is in like the 2014 vision, there was this sort of like inherit heritage of this where like there was these primitives where you would actually create uh a vertically decentralized technology stack where you could actually create real decentralized applications. Um you know it has been 20 years and um there's quite a few shortcomings right like imagine how uh it is to access like your you know a popular decentralized application today um the reality is is if you're on a desktop and using you'll probably use your browser uh you'll probably type in a URL and click on something uh you'll immediately start using uh a name service to uh resolve it typically that you know uh it's DNS uh then you'll be accessing a client server model, right? Um, and uh once you've got your front end from that server um over the web, uh it's most likely going to be using some kind of uh trusted another client server model in terms of accessing the crypto network, right?
um you know in terms of our public mempools they've become professionalized and become a more centralized uh and at least in the you know in like the sort of dominant networks uh that we have today our accounts are synonymous but public as well as our transactions um worse is most of these are actually still happening over clear protocols and while I've said most of those things you've probably thought of some project or some startup that has identified this as an issue and has been working to resolve it. But we have protocol fragmentation. If you wanted to be a purist today to access a decentralized application, it's incredibly high friction for an end user to do that. They probably have to download like an IPFS node. Uh if it's on Ethereum, you're probably downloading both a consensus client and a uh execution client unless you're using Nimbus.
Um and then you have to maintain these. And then then finally if you know where you want to go you can access uh through a C or content hash. So kind of like the best in the class that we really have today is like some kind of combination of a couple of protocols right if we really care about privacy you're probably thinking about using an anonymizing network like tour and combining it with uh your favorite uh private transaction system such as like Monero or ZCash. Um the issue with this is like well you know a general purpose anonymizing network uh has its own issues. uh it's you know depending on how you parameterize that network uh you know there's different ways you can uh trade it off but if you imagine it as an economy or a sociopolitical system um something like tour can't really maintain its economy u it needs to rely on something like Monero or zedcash um at the same time Monero and zcash don't really inherently um protect the the network level privacy I mean monero is doing a great job with dandelion plus Now, um, but then like if you're still even if you're using this, if you're accessing an application over tour, it's still inherently relying on like this sort of client server model, which is quite a shame because like the author has done Free Haven beforehand and I'm really waiting for him to get back to it.
Um, so the question is, is this the best we can do or can we do better? The ideal is basically we need to have network level privacy. uh we need to have private programmable transactions. Our front ends basically need to be hosted across the entire network uh and be user verifiable. Uh we need to ensure that you have disintegrated access to these networks um and even from consumerfriendly hardware both in participation of securing the network as well as um accessing it from your phone or whatever.
Um ideally all of these protocols are integrated in some way. So the friction of actually participating in this network in the way that we envision um is done and of course it you know needs to be scalable if we want to have a decent anonymity set. So that's kind of what Logos is trying to aspire towards and what we're building right uh it's not really a new layer yet another layer one but it's a private by default decentralized technology stack. Um while there's many subsystems and many pro subprotocols involved uh as a developer of a decentralized application you basically get three major sort of pillars of primitives. Um so this is anonymous networking and communications uh decentralized file storage as well as private smart contracts.
Um so we can basically in building such a system you can split it over these domains of concern. Uh in the interest of time I'm going to skip it a little bit. Um, and we need a decent foundation to get started with. So, we have to start with anonymous communications. Um, we work on a private peer-to-peer messenger/ mobile Athereum client called Status.
Uh, and over the years we've learned a lot about anonymous uh networks. Um, it turns out that depending on the traffic type that you're trying to uh cover, um, and the sort of trade-offs and properties that you want, uh, there's not like a one-sizefits-all solution. Uh, there are issues with onion routing. There are issues with mixn nets. Um, and in our case, there were certainly issues with remalers or flooding gossip subn networks.
Uh so this has led to us creating um a sort of framework called lib PDP mix in which we can actually parameterize for different traffic types. So for example uh you'll have um I'll give an example a little bit later on. Uh but here you you know you're thinking of basically a mixet um in one instancation but if you need more throughput you might consider you know onion routing in certain scenarios. Um but here we were largely just thinking about sender unlinkability right um lip pipe mix is not a transport in of itself it's an overlay protocol and so it actually allows us to basically uh mixify or you know however you want to anonymize your um your sort of standard lipid protocol and it's all got the good stuff that you'd be aware of you know syncs packet routing um we can parameterize in different ways and we have uh anti-PAM measures as well uh which is also pluggable. Um but you know this is for nodes that have like decent bandwidth.
They probably have less churn rate. Maybe they're participating in consensus. Uh so this is kind of like the core of the network, right? Um but there's also an issue if you're actually trying to connect to this from a high churn device such as your uh your mobile phone. Um and so we have like uh another protocol uh which was uh it's been known as WAKU uh where we essentially have a sort of flooding gossip sub uh network and it's largely focused on doing receiver unlinkability right um so you can kind of choose your level of participation in this network and uh there's various other sort of uh subrotocols towards this such as like filtering the kinds of messages they actually care about.
um if you turn off the network, you log off and you want to come back, you might actually want history, right? And if you're developing a decentralized application, there's certain scenario certain scenarios in which um you might want an ordered log or like the sort of messages you want to send are not really worth putting on u more heavier systems. And even though I kind of glossed over that in the interest of time, this is a 30-minute talk compressed into 20 minutes, so I apologize for that. uh those two protocols I also want to highlight just how impactful and transformative they are and like if you think about tour uh it has been at the center of some of like the largest sort of revolutions in our modern era from like the Hong Kong umbrella movement to Arab Springs and what's interesting about these sort of movements is like they're able to carry capacity um they tend to be like collective emotion um but if there is a chance for uh change in say like regime. Um very often there isn't any sort of like plan for new governance and that's where we kind of need to start thinking about a sort of l a lamportian uh part-time parliament parliamentary sovereignty or a blockchain uh public blockchain.
Um so we provide uh we've been developing um a sort of integrated multi-chain network. Uh it's uh at its core it's basically it state transition function is risk zero. Um it has zero cache semantics around it. Uh we've developed a private proof of stake um and a parameterized network for block proposal on linkability. Um and it's multi-ledger by design uh because you know the rate of change in ter in terms of the garbled circuits MPC FHE uh zero knowledge proofs is changing quite a lot and we want to be able to have multiple versions of these state transition functions and kind of upgrade or grow with that research.
So ah the reason why we have a risk or the the base layer it uses a a UTXO model um the UTXOs is a general purpose data model uh and then we can use that in terms of uh for doing various sort of state transitions um but we do we basically use um the root chain as uh for providing services on top of that um and you're probably familiar with uh block relay um censorship as a result of tornado cache and so on. Um and we were thinking about this quite a lot right so a lot of people have been discussing like the use of mixets for this uh but uh there is a bit of a problem with it mixets effectively get their uh anonymity through delays and so if you're work uh using something like um consensus traffic you have to look at understand the nature of that traffic and it's basically a bunch of synchronized senders right so let's say you had a hundred a thousand 10,000 validators or you know miners or whatever uh they're effectively sending a wall of traffic at regular intervals. It's incredibly deterministic. Um and if you want to put that through a mixet, it's going to blow out your delays far beyond um what you want in terms of a block production rate. In our case, it's one over 30.
And so we had to parameterize um lipid mix to basically uh create a sort of hybrid between these. Um it's kind of like a hybrid between a flooding gossip sub uh and a mixet. Uh and the reason we have we have to incentivize and disincentivize uh the cover traffic as well as the the allowable uh block proposals uh in a certain uh period. And the reason for doing that is basically constraining bandwidth. Um so this is basically you know you're using things like packets uh you do your routing through those you're sending out five different one um different paths but through a flooding gossip sub um and it turns out that we are able to minimize the amount of bandwidth get uh dispersal uh as fast as possible in in approximately 20 seconds and we believe under an act active adversarial model of roughly uh 20% active uh active advers neessary and 10% churn nodes that we can delay the linkability from a block proposer and their block proposal by about seven years.
Um so proof of stake making private proofs of stake uh I don't want to start any new walls uh wars here but like it's probably actually easy to think conceptualize this as something like proof of work um in terms of how it's difficulty adjustments um this is like most proof of stake systems require some like validator set like a known validator set and a known total amount at stake right um in our case uh we are able to get rid of that uh both of those requirements by essentially um requiring like uh the amount that can be at stake to be aged in the previous epoch of consensus. Um and then uh when it comes to actually inferring the total stake uh we use Robert's Monroe stoastic approximator. And so what this is is a basically an ability to be able to learn a value um through a corrupt signal. And in our case, that crop signal is the block production rate, right? So if uh we're seeing many block proposals, that means the difficulty is too um too easy.
And so we can uh we ramp it up and the the inverse, right? And it turns out in our simulations that we can accurately predict this within like a 3% tolerance. Um yeah, uh I know I'm glossing. Yeah. Right.
So private program transactions. Um, like I said, this is zero cache semantics. Uh, so you know, if you're familiar with ZGcash, it's like shielded transactions. Uh, in our case, um, every coin or UTXO has a ledger ID associated with it for a particular zone that it's operating in. Um, and, uh, it has pro, uh, programmable spend roles.
The main thing is that kind of different here is we've updated the cryptography a little bit. There's basically two proofs. uh one's a Merkel mountain range and one's an index Merkel tree for both your commitments and nullifiers. This means you don't need to maintain a giant list of serial numbers. Um I know I kind of glossed over that if you're more technical.
Uh there's a talk that I did at Protocolberg. There's a QR code um where I talk a bit more about the technical details of that if you're if you're interested. So um yeah, we have this basically like the sort of uh secure route or core. This is kind of like in a you know, we conceptualize this as kind of like a UFI bios. Um where we actually expect most of the transactions to be happening in like what you might consider to be called rollups.
Um it's not quite like roll-ups. We call them zones. Um but they're effectively the same sort of thing, right? you have execution that's happening um on these other sort of like chains. Um and they you know there's a couple of requirements that we need for another service that allows us to do uh atomic transactions between uh zones in a private way.
Um they support blobs, they support encry uh encryptions. Um yeah and it's actually very like from our data availability sampling it's incredibly light to verify any zone which is important for light clients. Um yeah, I mentioned one of the the uh I mentioned this already, but like we have an intent-like system that's entirely private. We call it packs or private atomic cross transactions. Um basically this allows the aggregation of like partial transactions with hidden inputs and outputs.
Um only the relative balance uh plus uh that equals the fees is revealed. Um yeah and these are all all these partials effectively ZK aggregated um and gives you this sort of cross zone consistency proof that allows for transactions between zones um and the fee capture for the executor can also be u in a separate partial uh du so um one of the zones we we're working towards having uh at getgo is uh a way to kind of interface with accountbased models and the sort of private uh UTXO model. Uh and so we've been one way to think about this is it's kind of like Aztec um but you can do things in a single transaction whether it's you know public to public, private to private or vice versa. Um so yeah it's a state separation architecture. You can basically run smart contracts both in public or private state or move between them.
Um, and uh, yeah, uh, that's pretty much it. Um, I wish I could go into more detail, but uh, yeah, um, we care about resource restricted devices a lot. Um, we're very concerned about being able to run this um, on laptops and particularly on mobile phones, right, or smartphones. Um so pretty much anyone that's participating in the network is effectively a light client uh is is basically help helping verify uh whatever zones that they actually care about. Um light clients are were a by default decision uh to start with.
Um they have yeah um that's it for the sort of uh blockchain aspects of it or the multi-leger uh multi-chain aspects for it. Um who remembers I mean you know the by bit hack right show hands by bit hack. Yeah. Okay cool. Well uh for those who who didn't uh basically um you had uh the CI the continuous integration deployment um of uh Nosis safe was compromised uh by a hacker by leveraging uh a safe employees uh lap uh credentials.
Uh no one was aware of the injection. nosis safe basically worked except for a target targeted attack uh on a particular uh group in this case by bit. Um and this kind of shows the inherent issue of like the client server models and like why we can't really trust uh running our front ends on just a website on a web server. Um so we've also been working on uh a decentralized file storage system. Um it's kind of it's it has content hashes that compatible with IPFS.
Uh but it's um we disperse the sort of blocks around the entire network to avoid like notions of pinning or as a result the inverse of pinning is like censorship, right? Um we have automatic repair and dispersal. Uh there is a marketplace that we're working on um that uh allows you to collateralize. Yeah, cool. Thanks.
Um yeah, we have Reed Solomon and Graia coding. Uh we've been working really hard to try and make this consumer friendly. Um and we managed to get this sort of proofs uh down to around 5 minutes uh with 16 GB of memory. So perfectly adequate on a laptop. Um and we're working to haven't done it yet.
There's still a bit more R&D, but we're working on like oblivious queries. So if you make a query in the network um other participants will not be able to understand you know what you're actually querying um or the content of it. Uh we also work on open hardware. Uh we're we're currently coming out with key card shell. Um it's a hardware wallet uh that has a secure enclave on a smart card.
Uh the entire thing is completely open source. Um, we implement a bunch bunch of things. Um, that's pretty much it. Um, I know I've been ranting. I've been going really fast.
Probably not giving you enough details as much as I would like to give you, but it basically what Logos is, it enables to you to build private uncensorable decentralized applications. Um, so when Wel is happening, uh, it's a little bit early for us to be talking about this, but it's been going on for roughly about 5 years. Um we're still working on it. Uh we believe that we'll have our specific like we have specifications. They're not in a single repo yet.
Um they're between teams and internal documents. We're going to be publishing those. Uh all of these protocols exist already in uh in some form. Uh we need to integrate them and we believe we'll have a test net out for this uh sometime next year. Um but Logos itself is is more than just that.
Uh we also want to rebuild civil society. We want to bring crypto into the real world. Uh and so we're building out logos circles where we're actually starting to exercise like practical politics, uh do community developments, um to actually start building out a parallel society or a parallel economy. Um yeah. So I also wrote a book on a lot of the sort of motivations and concepts.
It's called Farewell to West Failure. Um, if you go to logos.cobook, you know, there's a PDF you can download. It's uh CCA. Um, logos to co is the website.
There's an onion if you're if you're so inclined. Uh, but yeah, that's uh that's it from me. Thank you. [applause]
Automatic transcript — names and jargon may be misspelled.