Swarm Community Call — June 2025

Hello, hello everybody and welcome to June's Swarms community call. Summer is here already uh here in the north hemisphere of course and we are broadcasting live to all the corners of the interweb then that includes streaming on X. So hello there and you're very welcome to join the conversation in Discord. Thank you for coming. My name is Antonio and I'm very glad to be your host today wherever you are within this pale blue dot.

All right, let's kick in. And what can you expect of the call today? Here's the agenda. We will have core development updates with Callum and Lubisha. We will have a very very interesting talk long awaited talk uh in the community talk section that will be called swarmmonomics a new research program launched for the token economics of BCZ.

Then we'll continue with another community talk where we will have uh amazing uh breakthrough um changes you will see about per about performance and UX innovations by Athena with Miroda Corte and finally we'll conclude with our classic community AMA and open space for debate. So without further ado, let's begin and we will begin with the core development updates. And for that I would like I would like to uh invite to stage Callum and Lisha if you can raise your hand please. There you go. I got you.

I got you. And they will speak about hopefully they will speak about a B 2.6.0 zero uh that has been postponed during some uh testing and some results that uh that happened recently. Better safe than sorry.

Uh so Callum, could you give us some uh light of all all this uh development?

Yeah. Hi Antonio. Um hi everybody. Um, basically it's been postponed just like you say to be better safe than sorry and just to kind of really scrutinize our own kind of uh testing rigor and with the primary principle being that the network must not in any way, shape or form be compromised at all. Um, and that's why we just postpone and release it.

We don't feel that that's um necessary. I think in the wake of Ethereum updates and Solia in general and our own test net setup and configuration, it just seemed like the prudent thing to do was just to hold off and test a little bit further. And for any of the actual technical updates of where we were, what the problem was, what we're testing, what's fixed now, I'd give that over to Leisha to go a little bit deeper. Oh, so yeah like um like over the past few weeks um we had made some significant progress in uh improving the node spin up and uh transaction handling. Uh spin-up improvement uh had reduced the time required to update peer status and significantly accelerating the node init initialization and readiness.

Uh we also refined our transaction cost estimation process and previously we relied on outdated methods that produced inaccurate uh estimate. Um now we calculate cost based on the latest blocks base fee combined with the suggested tip. Uh and this will enable us to develop more precise and reliable estimate. Uh as mentioned on the release side, yeah, we did had delays uh the delays occurred because uh first of the transaction fee um and we wanted to allow node operators to participate in the red distribution game more fairly. Uh, additionally like significant updates to the not spin up process um, which now uses a postage snapshot data required us to improve our testing procedures to ensure absolute confidence in these changes uh, because those are really uh important details.

So to strengthen our testing, we are working on a fully isolated testing cluster with dedicated smart contracts and uh isolated mainet cluster to try to simulate uh future migration. Um these efforts will drive smoother updates and greater system stability. Um also we are actively refining our testing processes to improve reliability. uh but we are still uh setting milestones uh according to our priority. Um so our priorities for the next phase include further improving of our testing framework and uh updating the handshake protocol as proposed by MFW.

Uh we are also investigating how to implement fair TCP listener for the websocket protocol. Um also we are we plan to collect the detailed metrics on the pulsing protocol to be able to estimate its performance. Um to further improve our testing coverage we are evalating which beekeeper checks can be refined uh to to ensure better validation. And so those are some steps that we are uh doing in the in the next period. Although I want to apologize MFW because we still uh haven't reviewed his PR, but it's on our radar and uh I hope we'll do this as soon as possible.

And that that that's it for me.

All right. Thank you so much Lisha and Callum. Uh very comprehensive. I think that the uh well a good test net. It's uh fundamental to have a solid network.

It's very I can I can stress enough any efforts going in this direction will result in a better experience for everybody using swarm. So good for that. I mean they can go very far. Uh we have previous examples such as what happened with Kusama that they even deployed a new token just for testing purposes. But it was it's uh as I said it's very very important to to make uh to make the network uh reliable.

Thank you so much. Um thank you so much for this and that was the part of the core development update. Please Lubisha and Callum stay with us. If you

could I stay one more minute to just give a quick update on the more product side of our engineering which is the multi please guest and then and then I'll not steal any more time or any anyone's ears for any longer than I need to. Um yeah, so equally on our other release schedules for more of the product related um concerns, we've obviously got what's in the works internally which is the multi-chain app and then obviously externally we have the in browser clients. Both of these applications put together creates basically this layer above Swarm in general as an infrastructure layer to be able to access it and use it much more simply without having to run your node yourself and know all the ins and outs and documentation to the full extent. So, incredibly useful products. On our side of the fence, the multi-chain itself, um, we have everything complete that we need to have as a requirement to be able to release it.

So, you can rest assured that it is complete and we're we have this under embargo basically until the right moment in time where we want to release it and we can get the right announcements, right PR, um, the right timing, uh, essentially. But it is there ready and free to test over at app.eform.org. So you can go there, use it.

We'd love the feedback. Put it in the discord uh as well. And there's the last few kinks that were ironing out in it, which are not even necessarily down to our product or our engineering. Um so um all feedback is welcome, but obviously what we're working on then once we release it, we've got our road map of the nice to have to come afterwards. That might be, you know, ENS integrations, multiple file uploads, email reminders, um disclaimers, you know, more chains, salana, etc.

, etc. So we have our full um road map and pipeline of the features that are nice to have that want to come next. But what we have is here works last few kinks and a release date is all that all that matters but it's here for you and everybody on this call to go and look at it use it and come back to it periodically over at app.eformm.org.

Other than that I'll be quiet. All right. Cheers. Thanks very much everybody and Antonio.

Thank you so much Colin. That was quite informative. Thank you and please stay with us just in case something pops up. Uh I would like to remind everybody that you can leave your comments on the stage chat which is a different chat from the actual chat that you will have clicking on the top left uh top right icon uh so that the questions will be answered even if the call is finished. Thank you guys and let's move on to our first community talk will be uh this talk would be about swarmomics that is tokconomics from swarm a new research program launched in order to evolve and potentially improve the tokconomics that the our current and beloved uh token has.

um swarm swarm is entering this new phase where the economy it's starting to matter really really much because uh it's getting real and real economies demand rigorous observation modeling and principal policy. So for to meet the demand of transparency because everything needs to be publicly showcased and principal protocol designer research and I love the name I will undertake a year-long program of econometric and mechanism design you know the opposite of game theory to support a robust scalable swarm economy I would like to welcome Andrew from Shuka Research and Ata to take us through the plan.

Hello Andrea.

Hello.

Thanks for the invitation. Um going to try to share my screen for a short presentation. Uh

all right. I can see it. Is uh visible now? Full screen. It is for me.

Okay, great. Well, probably for everybody else, too. Um, oh dear. Yeah. So, thanks for the intro, uh, Antonio.

I'm very excited to be starting embarking on this program. Um, just to repeat the intro a little bit. uh Stuka research that's me and Arta will be undertaking this year-long program which we call swarmomics to as an external research contributor and we'll be doing incentive mechanism and market design research and econometric studies uh with the aim of mapping out the swarm's economy and introducing principled approaches to protocol design and improvement. So far beyond tokconomics of the Buzz token, we're also going to be looking at the structure of Swarm's its internal economy, supply and demand, pricing mechanisms, that kind of thing. So, here are some of the questions we're going to be thinking about.

Um, what does the competitive landscape of the swarm node market look like? What do I, as a node operator or potential staker need to know before entering this market? Uh, what kind of APY am I going to get? What kind of strategy should I use? Um, is this form of storage market liquid enough to respond to a big surge of demand that we all hope is coming from these wonderful new updates that are being made on the product end?

Um, how does the price quoting mechanism work? How well is it working? Um, is it responsible responsive enough to uh signal that more or less supply is needed in responses to changes in demand? Uh, are fluctuations in these prices or the buzz token price affecting demand by scaring off users? uh how well does the price oracle behave dynamically?

Will it converge to something stable? Will it fly off to infinity or go down to zero or will it wobble around wildly? And uh what given answers to these questions uh can devs do something? What are we going to do about it? What kind of improvements can we make?

How can we make principal datadriven choices for protocol parameters? So how to engage? What is what is this going to produce? Uh we'll be doing monthly updates shared in Discord's research channel. Some of you have already seen that we've shared the first update from May uh already and then the next one for this month will be coming in a few days.

As well as that, we'll be outputting various research notes, memos, and uh publishing a dashboard with data visualizations. And if you want to get in touch, just ping me or in the discord. Uh just anything that anything you want to feedback or to discuss about some of these research topics or suggest other topics, um let us know and we'll chat about it in the research channel. Ethereum and proof of stake handle similar use similar issues and you think this is the way that we should be or the network should be considering or should be some other ideas in terms of this uh this resilience to to volume changes.

Um yeah, so I guess you could be talking about a number of things there. Um if if we're so some of the questions which apply to both equally to both Swarm and to Ethereum are related to the price quoting mechanism. Um and maybe is that is that what you were talking about like Ethereum's base fee in a similar way for storage controller?

Yeah. So while of course Ethereum's research community has you know is much larger and there's more been more work done on the dynamics of those the Ethereum EIP559 controller and it's um game theory. Uh actually in terms of uh parameter choice even the mainet hasn't really had uh a proper study done to make decisions about how these parameters should be chosen. It's kind of a bit of a gap that's been uh acknowledged by some in the community. Um but there are certainly transferable ideas of things that have been done such as um sort of qualitative dynamical systems type studies of how the price controller operates.

Um you formally it's extremely similar to swarm and we're going to expect to be doing some work trying to transfer some of those ideas.

It's pretty cool

as as well as introducing uh new ones trying to use data to actually um suggest parameters such as the learning rate. learning rate.

Did Did this answer the elasticity question for you though, Antonio?

Yeah. Yeah. Yeah, it does.

Okay. Okay. Cool.

But I have another one which is uh because I went I I went to the GitHub and I couldn't help but to to focus on the stable coin design for stability. And I would like to to ask

that's a which is a whole it's a nice it's a nice topic. And I would like to ask you uh when thinking about stable coins, do you think it should be collateral based? It should be market base or it should be algorithm. You know the three types of uh stable coins that are around. Which one do you think will resonate more with uh with swarm?

I I I think this is not this is not something that you can even produce a like a collateral for. You you can't you can't you can't really back this as some type of battery, but it should be something that is I guess in a I guess in a sense it's algorithmic, right? You should you should be able to trade you should be able to redeem that stable coin for some type some number of uh bytes bytes per epoch.

Hold on a minute guys. Can I just make sure we're all talking about the same thing here? Um are you talking about Antony? You're asking about the storage stable coin idea.

Yeah.

Yeah. Let's make sure. Okay.

Okay. Yeah. Fine. Carry on.

Yeah. Yeah. Um yeah. I I think this should like if we're talking about like swarm in particular. Yeah, this should be like about the number of chunks chunks uh per a chunk block.

A stable coin should be linked to the chunk block.

Interesting.

This is the idea. It's not more it's not it's not more complex than that. I'd say to to clarify in terms of the uh the roadmap for this project, the storage stable coin is kind of more of a long range research idea and there are many more things to work out and we're expecting to get round to tackling that in the latter half of the project. So um at this point take

have to say about it right now is sort of a at the at the ideation stage.

Yeah, of course. Of course, I I

right now I would say it's a it's a thought experiment, but but but I I do think there there are very concrete questions to work out and that is that is part of what is swarmomics.

Awesome. Awesome. I just wanted to tease you guys. Thank you. Thank you for that.

No, no worries about that. It's not going to be carved on stone what you just said. It will be recorded and and it's h it's it's great to to have someone thinking on on this which is a long-term uh plan for Swarm and the well, it's part of the world domination roadmap. So thanks a lot.

Thank you guys. Thank you for this and as uh please stay with us just in case someone pops up with some some other some more questions and uh that's it and thank you. I will slightly but uh firmly move you to audience but I will keep an eye on you over there. Thank you and we will keep on with our community talks and then we will speak. Now we will speaking about performance client performance and UX innovations and to talk about this we will like I would like to invite Mirao towards us.

Uh so I think that the mirror is about to present is going to resonate very much with the builders in the room that the room that comes from the net world because uh we we'll hear about BNET which is a storm client built entirely on C C++ there are high performance primitives uh running on on net with impressive speed speed gains and second we'll take a look at beehive which is a browserbased dashboard that has implemented some UX improvements. But not without further ado and not to tell you more, please welcome Milort.

Hello. Hello everyone. Thank you. Thank you very much. Uh I will try to share my screen now.

Good luck.

Uh yes. Next. Okay. Can you see it?

Two out of two. This is amazing. I am so happy today. Yes.

Yes. I can see.

Perfect. You confirm you you see the presentation.

I do. I do.

Yeah. Great. Great. So, uh today I will present uh the research performed by Eterna in last month and um I will present our research in the context of the two projects B.NET net and behive and I will perform a rapid overview over the all the points.

So starting with B.NET uh BNET is uh is become uh what I say um as development kit uh built with C for the net uh framework and is published open source with LGPL on GitHub. It is composed by uh is a collection of libraries uh published on the nugat and um each uh each library is focused on uh on a scope. We have a core that contains all the logic uh on the the core logic. We have a client that uh implements specifically uh connection client for 4B and we have um um a library to uh integrate uh better the core with specifically the husbet environment and uh what I'm going to show you with B.

NET net uh will be ported also on uh on native browser with was we are working on it uh but um still not ready but will uh will arrive. So uh what is uh bit.net net today. Uh this is a an internal uh framework that evolved in time. A start it was only a client for uh for B but uh it now integrates also uh high performance object-oriented swarm primitives that is uh integrated in all the codebase and uh with these primitives uh we um focused also on development of several abstraction abstraction uh to to use this uh these primitives like uh a chunk store interface with several implementation based uh on uh on the actual storage support for chunks that any application can uh implement its chunk store version.

have implemented a full hashing pipeline compatible obviously with hashing from B and uh this uh hashing pipeline uh supports also partial input streams uh there is a specific case when the input is not always received complete. So uh for example when uh when we push some data with HTTP and uh supports also the feature that we will explain later uh that is chunks compaction. We have implemented also a postage stamper with uh already supporting presented stamps. It also supports uh uh manta ray manifest manipulation and reading from any kind of chunk store. So to to publish or read any kind of uh contents we have implemented also feeds with the sequential and epoch.

So also these are supported in reading and writing. uh we have imple implemented also an high performance chunk data stream that I will uh go more in deep later uh with supports to uh to range uh readings and uh seek support. We have implemented with biton net also a chunk traverser useful for example when uh uh when we want to traverse um a tree of chunks for example for pinning scope and we have added also some useful uh u utility services to to manage complex uploads like directory like file and some uh helpful uh primitives like converters serializer to integrate with the uh net framework itself. Uh the first uh the first uh innovation that I want to present you uh is the our hashing speed improvements uh that we have uh uh implemented with this library and we have performed some tests uh with it um for for have a fair comparison between B and B.NET net.

Um the time capture has been done in code. So uh I we will uh not have any overheads about network uh communication and uh for for the instance I can show you also the exactly code changes that we made uh to measure the the timing around the hashing uh function. uh and we have disabled also the chunk storage stage because uh this is not useful to miss the the only hash the poor hashing function timing and so I removed for the test this code. Uh the code has been run on uh my notebook notebook uh with 16 uh CPU core and 64 GB of RAMs and uh each time has been performed on random files of 10 GB and I'm measuring uh B uh the last public version of B versus the last public version of B.NET.

So the result uh shows that the average speed of hashing with B uh with files of 10 GB is around uh 2 minutes 121 seconds. Instead uh our B.NET can hash the same files in uh 35 seconds in average. And this leads to an average speed improvements of uh uh 3.4 faster for B.

ET against uh beam that I think is a uh uh is a good result. This has been possible uh with several uh optimizations uh our side. Uh the first one, the most important probably is a parallelization of chunks hashing with all CPU cores. And uh we have performed also uh a lowlevel memory optimization using some uh uh high performance primitives exposed by net that allow to to work with uh array segments without need to copy memory. Uh obviously we are going to reuse as much as possible of the data structure and uh we also have uh implemented an optimistic hashing algorithm that I will show is required uh for uh for porting all these optimiz optimization with the uh feature of chance compaction.

Uh anyway anyway with next version I suppose uh uh we can also improve even more uh this uh this speed result. the chunk compaction uh that uh I already presented in um previous version uh on uh on some talks ago. uh has evolved um and um and basically I will introduce you again is uh an operation of mining on uh chunks to try to uniformize uh chunk hashes uh with a given postage bucket uh with a given status that can be any uh advantages of perform chance compaction are multip multiple uh one of these uh is that produ producing more uniform hashes can distribute better uh chunks to to nodes and uh um and another advantage is the actual cost reduction because uh uh lowering the the the required depth for the same postage batch uh tends to uh to use the full postage bimal theoretical volume limit. Uh this chunks compaction has been performed in different ways buzzed on the chunk type in the case of a mandary node chunk. Uh we already have an implementation of uh of the obuscation key and we will use it.

Uh that changing the key will uh will change the final hash instead for uh uh so with the mandatory we can keep compatibility with B. Instead with the intermediate uh and data chunks uh we are going to introduce uh the new recursive encryption that uh uh will be need to be integrated also in B to be compatible uh with optimized uh compacted chunks instead in case of single or chunks uh we can't apply by design uh this um this optimization because how single order chunks works. So we are we will ignore them. Uh the specification of chunks compaction is uh um is very simple. We have introduced a new parameter that is the compact level in a range of between zero and two uh elevated 16.

Uh so we have choose the same u um um the same range of uh buckets indexes and by default for compatibility would be the the value is zero if uh nothing is passed. Uh what this index uh mean? Uh it uh is the it indicates how many keys we want to test at maximum trying to find the first uh best uh fitting chunk. Uh this doesn't mean we will uh try all of uh uh the the test for the the the company level specific because we can stop also earlier with if we find find a best uh fitting chunk but uh but this is the maximum value and uh the first best chunk uh is the the chunk that we can uh fit in a bucket with the lowest possible number of already present collisions. The second uh specification that we required is that uh is that the execution must be deterministic.

So what it mean uh it means that uh with the same input and the same status of uh postage buckets the final hash must be the same. Uh so uh where um where will uh we will um save these keys encryption keys used to to compact chunks in the mray node as I said is simple because we will use the opuscation key so it's already contained with the manta node by by protocol uh install And if we are trying to compact uh compact uh a BMT route uh so probably an intermediate chunks uh we will keep the metadata with the mandary node itself linking to it. So we have introduced two um two metadata two new metadata. uh one is a recursive encryption that uh uh is a boolean value when uh uh it is true is false by default but if it's true uh this mean that intermediate chunks uh must be interpretated uh not as a simple sequence of uh reference hashes uh but uh a sequence of couples uh composed by a nash and an encryption key. So instead of 128 references, each intermediate chunks will be able to contain only 64 uh references but encrypted.

And uh we have introduced the the metadata chunk encrypt key uh to contains the uh effectively uh root encryption key. If uh the the chance compact is applied not on a BMT route as I said uh we have to look at the parent intermediate chunk uh with the pair hash and uh and key. what uh we found about the cost reductions with chunks compaction. By our test uh as I already published it on the behue um on GitHub, we have found um a cost reduction of eight times uh passing for example with this test from uh an average required depth of 20 to an average required depth uh of 16. And we have noticed that uh uh we uh have best results when we get near of uh two elevated hen uh with the number of chunks.

So in this case the required um compaction level will be higher but also also gain uh is uh is better. Uh what we have found uh uh integrating uh uh these uh uh optimizations uh about performance and uh uh about the chunks compaction is an apparent conflict of interest in the hashing pipeline because uh the parallel chunk uh hashing is required by performance and obviously um parallel hashing operation uh have concurrent access to to buckets for insertion. But the ter deterministic execution for tank compation instead requires an um an ordered insertion into buckets and uh we have found uh a solution for this and the solution is using an optimistic BMT hashing uh algorithm. Um and we can do this because uh uh we have found that the must uh EV uh operation is the actual hashing that anyway needs to be performed several times with the chance compaction. And we can do this optimistically in uh in parallel.

And then we can halt the the process uh waiting for the previous uh chunk that has been uh inserted in the in the in the buckets. When the previous one has been inserted, we can verify if uh the collision on the selected uh bucket optimistically is changed or not. And if is not uh because um the the inserting operation um um can only can only add a new new bucket if the the found one was the be the first best chunk. Uh we already know that this condition didn't change. So we can proceed with the complexity of uh O of one.

In the case instead of the optimistic uh algorithm is uh so the collision of the selected bucket changed. We can simply repeat repeat the search but using again the results the hashing result that uh has been cached uh with the previous operation. So anyway the second time is will be f uh very faster and uh in the case only new hashes uh must be computed. So anyway we keep an eye performance also in this case in this case another operation uh that we have improved with B.NET net is how we compose uh the data stream reading from uh uh um a three of chunks.

And uh if we we we if we see how this is have been implemented in uh B we can find uh that each chunk is readed once a time and in pre-order uh with uh three chunk um three of chunks. So at first the root is written then the first uh intermediate uh chunk um in the case of uh reading starting from the by zero and uh recursively we go down until the data and uh we proceed with the recussion uh one chunk at time and uh this is uh very uh time expensive Because uh in the optimal chunk store uh assesses case uh with n chunks the complexity is of and uh we decided to improve this in the case of the chunk store supports uh bulk uh bulk reads and because we have abstracted this uh the chunk store uh we don't know by before if the the store will support uh bulk read or parallel reads um and we have some cases in where this is true. So what we do instead is reading uh chunks in bugs by layer. So we start from root and uh from root we uh calculate where the range that we are trying to read uh receives. So we get the full layer or the segment layer uh calculating the left bound that we don't need and the right bound that we don't need.

uh receiving only the chunks uh that we need to for for the requested range and then we proceed to the end uh reading only uh necessary uh chunks but uh one uh with a single reads uh by layer and this can reduce a lot the the access time uh because Now with n chunks uh complexity is all of the high or uh in function of n is all of logarithm of n with the base uh 128 that's a much lower the read hes this is very useful for example when the chunk store um can parallelize the the reads. For example, when the reads are performed over the network or when uh um the chunk store is implemented with uh with a database uh for example uh for example uh the the application uh later that we'll present if uh the chunk store only supports a sequence read sequence reads uh nothing change and the performance are the game. Uh this new method supports range requests uh supports support data seek supports that uh partial layer hes and also implements uh um remaining layer caching. uh that uh allow to uh not read again the same layer if the the reading stream uh access layers uh with a buffer smaller than the requested um the requested part. What we already have readed once we will not read again.

uh and is uh uh optimize even more the performance. The second project that I want to uh show you is behive. This is a new project uh never seen before uh is a swarm meta node uh with local storage uh on database has been built on top of B.NET net and this now in alpha stage uh published open source with AGPL license. What is behive?

Behive is um scalable meta node with the high availability support in mind. So every component is filable and can be replaced uh pretty easily. Um it try it tries to keep uh big compatibility uh every where is possible and introduce some improved APIs uh out of the box when uh when compatibility is not possible. Um, it uses uh an array of uh swarm b nodes to communicate with the swarm network and uh already perform itself data hashing and chunks production storing them on a instance of MongoDB implementing also pinning on on it. Uh this is highly scalable uh because each component uh is independent uh behive itself is uh stateless.

So I can rise uh or destroy instances uh in any moment. Uh instead uh b nodes uh are stateful but uh I can add uh from one to hand without uh any problem. in MongoDB uh MongoDB implements its own scalability with replica sets uh uh shards etc. What you have uh implemented with uh behavior um APIs is three uh kind of different APIs. We have full B compatible APIs whenever is possible.

uh this uh uh could have been improved uh with not breaking changes. Uh but we have have also implemented uh other experimental or eternal swarm APIs with a new prefix uh version prefix EV v1 that um to to to to separate from uh the swarm uh versioning of v with v1. And the idea of these experimental or turn APIs is that we uh feel free to experiment on this. And if and when also the official B uh client will uh integrate them, we can deprecate our version and move to the new implementation or we can proceed with our versions uh without problems. And the third kind of uh APIs are specific to behive for example reading um reading the list of uh connect the B nodes and this is specific to this kind of application what we have introduced uh to API relevant changes uh the BIC API now supports compacted chunks both with upload and downloads and is uh they remains full compatible with B.

Uh BZ Z uh the same introduced supports to compet chunks and also is able now to resolve epoch feeds. Uh we have introduced a new uh API additionally to the the previous one uh from B uh for chunks to uh allow bulks uh updates uh uploads sorry. Uh, BA plus uh permits to uh use the full uh bandwidth of the network connection um allowing to uh send back uh um a lot of chunks altogether and uh and this eliminates the overhead of um sending one chunk by time. Um or this improved a lot also over the websocket version and I performed some test uh with uh 100 like on even more of person performance gain with the feeds API. We have implemented epoch feeds.

Uh we support compat uh compacted chunks with the feed manifest obviously not with single over chunks as I said pull back compatible with B and with pinning we are trying to evolving this uh introducing a synchronous pinning to not to not have uh uh to make clients wait for the operation to finish. We support also partial pinning results where a pinning could fail to find some chunks but this could be recovered later in the case and um we support recursively encrypted chunks with the chunk traverser and we have added also pinning of single owner chunks that was missing from the B APIs. We uh with our research we have also identified uh protocol vulnerability uh about single owner chunks in our opinion because uh by design it's a single owner chunks uh is recognizable from content addressed chunks and uh in this way any node can sniff all of them passing uh heat. But uh what we have found is that by protocol uh very often single chunks contains references or embedded chunks of root manta array uh nodes. And this is a problem because uh uh by feeds um feeds pro protocol uh these root nodes are always in clear and uh this mean that uh sniffing all single owner chunks.

Each node can have a perfect knowledge of the contents linked uh with these root chunks and uh and this is obviously uh is a vulnerability because permits to everyone to anonymize contents uh directly or indirectly uh linked by single owner chunks. we have found a solution uh on this uh but the solution can't be uh to encrypt the single owner chunks because uh how these are designed. So what we have found uh is that we can uh encrypt by default all the uh single owner chunk contents. So the reference to to the chunk or the embedded chunk and we can encrypt uh the content with a surf generated uh key uh when we want to upload a sock content or uh we can accept a custom key from user. Uh we can also have a constant key uh in the case of the feed and and in this specific case could be easy to store the sock uh key into the feed manifest itself to to allow uh a simple feed resolution as before with BZ zed.

uh what we have found is that probably uh sing uh the sore encryption is not a good encryption in this case because manta rays tends to have a common pattern of uh initial uh byes. So this would lead to uh an easier key scan attack. Uh not the full key space but uh more focused and probably uh another encryption method will be will be tested maybe uh AES. Uh anyway, with the next versions of Behive, we will uh provide um um a fix uh for this uh this issue with uh the new APIs and uh I'm going to add a bonus slider on this presentation announcing that we are going to uh release soon our swarm as a service uh gateway. Okay.

So to everyone uh that is developing on vers and needs uh some uh access to to the network can contact us at uh this mail or me personally and uh I want to to note that Eternal Research uh is selfunded since 2019 and we are always looking for investor or partners to help our research and development. Thank you very much and this is all by me.

That was fantastic swarm service gateway. Thank you. That's that's looking forward to test it. Thanks a lot.

Uh M. Uh there's a there's a comment however about what you said about SOC's by by uh I just would like to voice it out here that it says um that uh yes about the fact that most chunks are encrypted by default and they could contain some meaningful data in plain text. But they said he said socks are signed with arbitrary private keys not the note not the notes key. So well this is a clever strategy for finding data. it doesn't actually reveal who uploaded it or which node it came from.

So I I've studied the the source code of uh of be and found that uh the the mandatory node is published in clear uh and when is read from uh visa z uh is in clear u I maybe I could perform a better research um but uh anyway if A fix that will come will be later. So

all right,

I will perform more research but this is what I found at now.

Fantastic. Okay, thanks a lot MCO. Thank you very much for your comprehensive presentation.

Thank you. Thank you.

And let's move on to the last part of the call which is Q&A. uh for the Q&A um we have been formulated a lot of questions all about the token and well I would like to just to answer all of them with uh because they the questions are well is the about the price when token moon why do not why nobody know not the team is not doing anything for the token well if you just if you stayed here for the whole call you will you would have heard how there's this research going on to find out how effective the price oracle is at controlling replication date, how to improve transparency and lower the barrier of entry for node operators, how the demand response to BCZ and USDT volatility. Uh I mean there even a storage stable coin that would unlock elastic easily scalable cloud storage. So well for the financials over there that's the ability to create solid futures instrument. So I would say it's in the way.

Give it some time and the fruits will be born. And that takes us to the last part of our call uh with one hour straight. That's fantastic. If nobody has anything else to say, thank you. And I'm looking at you virtually, Mina.

No, that's it. So thank you so much. Thank you very much to the speakers, presenters, and participants of the call. It was great to hear your voice or your keyboard taps and of course thank you the audience. We are all swarm speak freely.

[Music] [Applause]