diff --git a/404.html b/404.html index 0adf8e10..23464c52 100644 --- a/404.html +++ b/404.html @@ -10,8 +10,8 @@ - - + +
Skip to main content

Archive

Archive

2025​

2024​

2023​

2022​

2021​

2020​

2019​

+ ) .lsd-dropdown__trigger:focus .lsd-dropdown__option-label{-webkit-text-decoration:underline;text-decoration:underline;}.lsd-dropdown__label{display:block;}.lsd-dropdown__button-container{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;}.lsd-dropdown__trigger{width:100%;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;border:none;cursor:pointer;background:none;}.lsd-dropdown__trigger:focus{outline:none;}.lsd-dropdown__option-label{cursor:inherit;white-space:nowrap;overflow:hidden;text-overflow:ellipsis;}.lsd-dropdown__icons{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-ms-flex-pack:center;-webkit-justify-content:center;justify-content:center;gap:8px;}.lsd-dropdown__icon{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;}.lsd-dropdown__supporting-text{margin:6px 14px;}.lsd-dropdown--error .lsd-dropdown__option-label{-webkit-text-decoration:line-through;text-decoration:line-through;}.lsd-dropdown--disabled{opacity:0.34;cursor:initial;}.lsd-dropdown--large{width:208px;}.lsd-dropdown--large.lsd-dropdown--error{width:230px;}.lsd-dropdown--large .lsd-dropdown__label{margin:0 0 6px 18px;}.lsd-dropdown--large .lsd-dropdown__button-container{height:40px;}.lsd-dropdown--large .lsd-dropdown__trigger{padding:10px 0px 10px 18px;}.lsd-dropdown--large .lsd-dropdown__icons{padding:0px 14px;}.lsd-dropdown--medium{width:188px;}.lsd-dropdown--medium.lsd-dropdown--error{width:210px;}.lsd-dropdown--medium .lsd-dropdown__label{margin:0 0 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__button-container{height:32px;}.lsd-dropdown--medium .lsd-dropdown__trigger{padding:6px 0px 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__icons{padding:0px 12px;}.lsd-dropdown--small{width:164px;}.lsd-dropdown--small.lsd-dropdown--error{width:186px;}.lsd-dropdown--small .lsd-dropdown__label{margin:0 0 6px 12px;}.lsd-dropdown--small .lsd-dropdown__button-container{height:28px;}.lsd-dropdown--small .lsd-dropdown__trigger{padding:6px 0px 6px 12px;}.lsd-dropdown--small .lsd-dropdown__icons{padding:0px 10px;}.lsd-dropdown--outlined .lsd-dropdown__button-container{border:1px solid rgb(var(--lsd-border-primary));}.lsd-dropdown--underlined .lsd-dropdown__button-container{border:1px solid transparent;border-bottom:1px solid rgb(var(--lsd-border-primary));}
Skip to main content

Archive

Archive

2025​

2024​

2023​

2022​

2021​

2020​

2019​

\ No newline at end of file diff --git a/rlog/atom.xml b/rlog/atom.xml index 5829dc72..df86f9fb 100644 --- a/rlog/atom.xml +++ b/rlog/atom.xml @@ -2,11 +2,317 @@ https://vac.dev/rlog Vac Research Blog - 2025-08-12T12:00:00.000Z + 2025-09-02T14:00:00.000Z https://github.com/jpmonette/feed Vac Research Blog https://vac.dev/theme/image/favicon.ico + + <![CDATA[Decentralized Message Layer Security (De-MLS) with Waku]]> + https://vac.dev/rlog/de-mls-with-waku + + 2025-09-02T14:00:00.000Z + + This post introduces de-MLS, a decentralized variant of Message Layer Security (MLS) +that reimagines group messaging by replacing centralized delivery services with peer-to-peer protocols +while retaining strong guarantees such as forward secrecy (FS) and post-compromise security (PCS).

+ +

Introduction​

+

Secure Group Messaging (SGM) is resource-intensive when aiming for robust security features +like forward secrecy (FS) and post-compromise security (PCS).

+

One straightforward approach to SGM is a pairwise group chat, +where each pair of group members establishes a unique encryption key using Diffie-Hellman. +While this method ensures security, it falls short in terms of practicality:

+
    +
  • High storage requirements: Each participant must store encryption keys for every other participant.
    • +
  • Inefficient encryption: Each message must be encrypted separately for every participant, +leading to significant computational overhead.
    • +
  • Inefficient message storage and delivery: Each separately encrypted message must then be sent over the wire, +whatever this wire might be. Or stored in database.
    • +
  • Cumbersome group management: Adding or removing users and refreshing keys becomes +increasingly inefficient as the group grows.
    • +
+

One scalable for Secure Group Messaging (SGM) is Message Layer Security (MLS), as standardized in RFC 9420. +Leveraging TreeKEM, MLS organizes group members in a cryptographic tree structure, +where each participant is responsible for maintaining specific parts of the tree.

+

While MLS offers scalability and strong security guarantees, +its reliance on server-based delivery services poses limitations for fully decentralized environments.

+

In this post, we present the implementation details of the first version of Decentralized MLS (de-MLS) +which is an SGM protocol. De-MLS can serve groups that cannot rely on central servers, +such as journalists and activists seeking secure communication. +It is also well suited for DAOs, where Ethereum-based authentication can restrict access to members +holding a minimum ETH balance, and for NGOs or research consortia that prefer not to host their own servers while still +requiring end-to-end encrypted group messaging. Decentralized MLS (de-MLS) satisfies the following features:

+
    +
  • Decentralized
    • +
  • Scalable
    • +
  • End-to-end encrypted (E2EE)
    • +
  • FS and PCS provided
    • +
  • Ethereum authenticated
    • +
+

Background​

+

MLS​

+

The Message Layer Security (MLS) protocol offers scalable and secure group messaging protocol +by organizing participants into a cryptographic tree structure, +enabling efficient operations like adding or removing members with logarithmic time complexity +relative to the group size. MLS provides strong security guarantees, including FS and PCS.

+

MLS assumes that two services are provided:

+
    +
  • An Authentication Service (AS): It enables group members to +authenticate the credentials presented by other group members.
    • +
  • A Delivery Service (DS) that routes MLS messages among the +participants in the protocol in the correct order and manage the keyPackage of the users +where the keyPackage is the objects that provide some public information about a user.
    • +
+

Despite its scalability, MLS has a notable limitation: +it is inherently designed for server-based federated architectures for delivery service (DS), +even when the servers themselves don't need to be trusted. +To achieve a decentralized protocol, the functionality of DS must be reimagined +to eliminate reliance on a central server while preserving the protocol's security properties. +Thus, we proposed decentralized MLS (de-MLS), +leveraging Waku nodes as peer-to-peer communication protocols to eliminate reliance on centralized servers.

+

Lastly, MLS operates on an epoch-based model, +where group state changes (e.g., adding/removing users or key refreshes) occur between epochs +that are always required to be conducted by a single entity. +For example, if a user is removed in epoch E, +the rest of the group members generate a new key in epoch E + 1 by passing the new entropy. +The removed user cannot decrypt messages sent after epoch E + 1.

+

Waku​

+

Waku is a decentralized messaging protocol designed for secure and efficient communication in peer-to-peer networks. +It operates as a broadcast-based routing layer where content topics can be used to tag and filter messages. +Users join channels by subscribing to specific content topics, +which determine the scope and type of messages exchanged. +This enables flexible and efficient communication patterns in a decentralized environment.

+

de-MLS​

+

Decentralized MLS (de-MLS) is a peer-to-peer secure group messaging protocol +that can work with any delivery service (DS) meeting a minimal set of requirements. +In this post, we highlight its integration with Waku as the messaging protocol, +while emphasizing that de-MLS itself remains agnostic to the underlying DS. +Further technical details can be found in the de-MLS RFC.

+

Decentralization is achieved not only at the delivery service (DS) level +but also within the authentication service (AS). +Multiple special nodes named Steward in the group serve as authorized identities to authenticate users +before they join or are removed from the group transparently.

+

de-MLS provides two different user management configurations, both utilizing the Waku protocol for DS:

+
    +
  1. Single Steward: +
      +
    • A single authorized identity (Steward) manages the group, +including removing or adding users with agreement among users by a voting-based consensus.
      • +
    +
    2. +
  2. Multi-Steward: +
      +
    • Multiple Stewards have equal authority to add or remove users.
      • +
    • A consensus mechanism ensures consistency by resolving concurrent changes +within the same epoch and preventing possible conflicts. +In each epoch, all modifications are managed exclusively by a single Steward.
      • +
    +
    3. +
+

Note: We chose the term Steward to reflect the role of transparently coordinating and organizing passengers at stations, much like Stewards do in transit systems.

+

In multi-Steward settings, de-MLS requires a consensus among Stewards +that have equal rights in the group since changes in an epoch in MLS are required +to be conducted by a single identity, that is the Steward.

+

For the consensus integration, ongoing research explores two promising approaches:

+
    +
  1. On-chain consensus mechanisms: +Outsourcing consensus to a smart contract solution for transparent and immutable agreement.
    2. +
  2. Off-chain consensus mechanisms: +Utilizing off-chain consensus protocols to design efficient, decentralized protocols.
    3. +
+

Waku Integration​

+

Waku integration is a crucial step in the construction of de-MLS, +aiming to replace traditional client-server communication with decentralized messaging. +The specifics of Waku integration will be detailed in a separate RFC; +for now, our main priority is the de-MLS RFC.

+

The main challenge in this transition is transforming the centralized Delivery Service (DS) +into a decentralized equivalent, which performs two essential functions:

+
    +
  1. Message Delivery and Ordering: +The DS is responsible not only for delivering messages to the correct recipients, +but also for preserving the correct order of these messages, which is critical for the consistency of group state.
    2. +
  2. Key Package Management: +The DS manages key packages, which are essential for adding members securely to a group.
    3. +
+

To maintain a truly decentralized architecture, +key packages cannot be stored in a centralized location. +Initially, we considered using a smart contract (SC) as a decentralized substitute for server-side key package storage. +However, this approach proved impractical. +Blockchains are immutable by design—once data is written, it cannot be fully removed. +This contradicts a core requirement of MLS: each key package must be used exactly once and then deleted, +to prevent replay or reuse attacks. +Instead, our solution is to require users to actively provide their key packages upon request, +allowing validation at the moment of use without persistent storage. +While this approach may lose some benefits of asynchronicity, +we plan to address this in the future by introducing store nodes that can temporarily hold key packages. +This ensures both compliance with MLS's security model and alignment with decentralized system principles.

+

Flow​

+

The flow section explains the processes that +when a user wants to join a group in both Steward and users side also their interactions. +The flow of de-MLS is as follows:

+

Figure 1

+

1. Steward joins the welcome topic​

+

The welcome topic is a topic created and monitored by the Steward for a specific secure messaging group, +allowing any Waku node to subscribe permissionlessly. +Being in the welcome topic does not imply group membership, +it acts as a waiting room where users can send their key material, +which the Steward listens for and processes before granting access to the secure group.

+

2. Group initialization​

+

Steward initalizes a group with parameters such as cipher suite and group ID.

+

3. Emitting Group Anouncement (GA) by Steward​

+

Steward creates group announcement (GA) periodically to the welcome channel +that the users can find the who the Steward is. +This will be important for the next step.

+

4. User joins the welcome topic​

+

As first, the users who wants to be part of the decentralized MLS should subscribe the welcome channel. +Then user can find the group name and also corresponding GA message from Steward. +This GA message helps the user to create a valid keyPackages which define in section 10 +in RFC9420 for the group.

+

5. User creates its key package​

+

User creates the keyPackage and encrypt by public key of the Steward then send it to the Steward. +Since the message is encrypted, stay secure though the welcome (permissionless) topic.

+

6. Steward receives the User's key package​

+

Steward receives the user's keyPackage and decrypt it. +After decrypted, Steward also verifies the validity of the keyPackage by signature verification. +If the keyPackage is not valid, the Steward just drops the message, +otherwise it moves to the next step which is proposal creation.

+

7. Creation of Voting proposals​

+

Voting proposals are special MLS application messages that may come from any participant, including the Steward. +In this context, any member can create a proposal corresponding to the user’s keyPackage. +In regular MLS, proposals are automatically converted into commit messages, +which can change the structure of the tree. However, in de-MLS, since the process is decentralized, +proposals must be voted on before being converted into a commitment.

+

8. Voting for proposal​

+

Voting applies decentralization by protecting small groups can control. +Therefore, proposals must be voted on before committing. +The consensus mechanism should be a lightweight consensus that cannot be a bottleneck for treeKEM scalability. +Basically, the consensus returns the binary result for a given proposal. +If voting result is NO, the proposal is dropped; otherwise, the Steward transforms it into an MLS proposal. +MLS proposal message is a distinct type of MLS application message, +where the Steward attaches the voting result instead of directly releasing a commit message.

+

9. Creating commit message​

+

Commit messages are the messages that start new epochs. +They include key and tree material that existing members can use to generate the new state of the tree.

+

After Steward gets the YES from consensus, Steward creates commit messages +that injects new entropy for the existing group members.

+

10. Sending messages​

+

After Steward creates and then sends two messages:

+
    +
  1. Commit message informs existing group member to update their key +to align with the new member’s key for the upcoming epoch.
    2. +
  2. The welcome message informs the newly joined user to generate a group key +that matches the key existing members will use in the upcoming epoch.
    3. +
+

Although existing users had different group keys in the previous epoch and the new user had none, +the Steward message ensures that both existing and new users converge on the same group key in the next epoch.

+

11. Applying welcome message​

+

User can generate the next epoch group key by using the welcome message as well as +existing users extract the same groupKey by using commit messages.

+

The commit message helps existing members generate the next group key Gk+1, +while the welcome message helps the newly joining user generate the same Gk+1. +This provides two important security properties:

+
    +
  1. +

    Forward Secrecy (FS): +The new user cannot read previous messages since they were encrypted with the old key Gk

    +
    2. +
  2. +

    Post-Compromise Security (PCS): +If a user is removed from the group, +they cannot read future messages since those messages will be encrypted with the new key Gk+1

    +
    3. +
+

Benchmark​

+

This section presents the performance evaluation of de-MLS. +One of the key advantages of the MLS protocol is its efficiency, +as it eliminates the need for pairwise message exchanges between all participants. +Instead, the decentralized DS enables the addition of new participants by sending only two messages to the group: +a commit message and a welcome message. +However, despite this advantage, the protocol does have certain bottlenecks, which are as follows:

+
    +
  • Firstly, the Steward must receive the key packages from each member wishing to join the group. +This process requires sequential message exchanges and involves computationally intensive tasks such as encryption, +decryption, and digital signature verification. +Even when multiple users are added to the group simultaneously, the process is essentially sequential. +The tree structure is updated one user at a time, +followed by sending the final commit message to the existing group members +and a single welcome message to the new members.
    • +
  • Secondly adding a member to a group requires rebuilding the tree and computing new keys.
    • +
+

The following measurements were made as follows:

+
    +
  1. The time required for the entire sequence of receiving a user key package is presented here. +This includes generating the Steward key, creating messages with signatures and encryption, +and processing these messages.
    2. +
+

Share Key Package - 1.8395 ms

+

Note that these measurements do not account for the time taken to forward messages.

+
    +
  1. The time required for creating the commit and welcome message +from a ready-made package bunches is shown in this table.
    2. +
+
Group Size (by users)Time
101.8662 ms
10014.124 ms
500121.85 ms
1000412.39 ms
5000~ 15-20 s
10000~ 1-1.5 min
+

The tests were conducted on the following configuration: +Apple M3 Pro @ 4.05GHz and 12-Core CPU/18-Core GPU.

+

Here, the network latency and the time taken by users to apply the received commits are also excluded. +These aspects are planned to be measured and evaluated in future work.

+

Potential drawbacks and countermeasures​

+

Since de-MLS replace the servers by P2P, we could lose some good features of servers based MLS. +In this section we present the potential drawbacks and possible countermeasures of de-MLS.

+
    +
  • Offline users: keyPackages are provided by the users directly without any storing, +this is required each user must be online for joining to a group. +
      +
    • We can consider to use Waku sync nodes +that are nodes has storing ability for a temporary storing of keyPackages.
      • +
    +
    • +
  • DoS attack to Steward: Steward is known in welcome message from periodic group announcement message +so Steward can be targeted for DoS attack. +
      +
    • As always we consider to use Rate-Limiting Nullifier (RLN) with Waku to protect network from spam.
      • +
    +
    • +
  • Message loss or delay : Because of P2P and consensus settings, message can be lost or delayed., +
      +
    • We can integrate reliability mechanisms to Waku such as +scalable data sync (SDS)
      • +
    • Consensus mechanism requires to provide liveness property against offline nodes, for example, +it may provides default YES or NO options for a silent users who do not vote.
      • +
    +
    • +
  • Enchanced authentication +
      +
    • Ethereum authentication could be inefficient. +We can configure the authentication mechanism for example asking minimum balance or etc.
      • +
    +
    • +
+

Conclusion​

+

To summarize, the approach to solving decentralized DS tasks with Waku +can be outlined as shown in the comparison table:

+
FeatureMLSde-MLS
Message DistributionMessages are sent from the server to clientsMessages are sent by publishing/subscribing to pub-sub topics
Commit Message HandlingRelies on a serverRelies on a consensus and transparent Steward
Key Package ManagementKey packages are stored and distributed by the serverKey packages are provided by the users themselves
+

Future Work​

+

In the next iterations, the implementations are planned as following:

+
    +
  • Dual-Consensus Multi-Steward Support: One consensus mechanism selects an Steward from all users, +while a second governs group decisions among the elected Stewards
    • +
  • Consensus mechanism for handling concurrent changes within the same epoch
    • +
  • Key rotation support
    • +
  • Benchmarking for the multi-Steward configuration including the network time
    • +
+

References​

+]]> + + Ekaterina + + <![CDATA[Scaling libp2p GossipSub for Large Messages: An Evaluation of Performance Improvement Proposals]]> https://vac.dev/rlog/gsub-perf-imp-comparison @@ -5629,104 +5935,4 @@ aligning incentives with the blockchain’s broader consensus mechanism.

Richard - - <![CDATA[The Future of Waku Network: Scaling, Incentivization, and Heterogeneity]]> - https://vac.dev/rlog/future-of-waku-network - - 2023-04-03T00:00:00.000Z - - Learn how the Waku Network is evolving through scaling, incentivization, and diverse ecosystem development and what the future might look like.

- -

Waku is preparing for production with a focus on the Status Communities use case. In this blog post, we will provide an -overview of recent discussions and research outputs, aiming to give you a better understanding of how the Waku network -may look like in terms of scaling and incentivization.

-

DOS Mitigation for Status Communities​

-

Waku is actively exploring DOS mitigation mechanisms suitable for Status Communities. While RLN -(Rate Limiting Nullifiers) remains the go-to DOS protection solution due to its privacy-preserving and -censorship-resistant properties, there is still more work to be done. We are excited to collaborate with PSE -(Privacy & Scaling Explorations) in this endeavor. Learn more about their latest progress in this tweet.

-

A Heterogeneous Waku Network​

-

As we noted in a previous forum post, Waku's protocol -incentivization model needs to be flexible to accommodate various business models. Flexibility ensures that projects -can choose how they want to use Waku based on their specific needs.

-

Reversing the Incentivization Question​

-

Traditionally, the question of incentivization revolves around how to incentivize operators to run nodes. We'd like to -reframe the question and instead ask, "How do we pay for the infrastructure?"

-

Waku does not intend to offer a free lunch. -Ethereum's infrastructure is supported by transaction fees and inflation, with validators receiving rewards from both sources. -However, this model does not suit a communication network like Waku. -Users and platforms would not want to pay for every single message they send. Additionally, Waku aims to support instant -ephemeral messages that do not require consensus or long-term storage.

-

Projects that use Waku to enable user interactions, whether for chat messages, gaming, private DeFi, notifications, or -inter-wallet communication, may have different value extraction models. Some users might provide services for the -project and expect to receive value by running nodes, while others may pay for the product or run infrastructure to -contribute back. Waku aims to support each of these use cases, which means there will be various ways to "pay for the -infrastructure."

-

In his talk, Oskar addressed two strategies: RLN and service credentials.

-

RLN and Service Credentials​

-

RLN enables DOS protection across the network in a privacy-preserving and permission-less manner: stake in a contract, -and you can send messages.

-

Service credentials establish a customer-provider relationship. Users might pay to have messages they are interested in -stored and served by a provider. Alternatively, a community owner could pay a service provider to host their community.

-

Providers could offer trial or limited free services to Waku users, similar to Slack or Discord. Once a trial is expired or outgrown, -a community owner could pay for more storage or bandwidth, similar to Slack's model. -Alternatively, individual users could contribute financially, akin to Discord's Server Boost, or by sharing their own -resources with their community.

-

We anticipate witnessing various scenarios across the spectrum: from users sharing resources to users paying for access to the network and everything in between.

-

Waku Network: Ethereum or Cosmos?​

-

Another perspective is to consider whether the Waku network will resemble Ethereum or Cosmos.

-

For those not familiar with the difference between both, in a very concise manner:

-
    -
  • Ethereum is a set of protocols and software that are designed to operate on one common network and infrastructure
    • -
  • Cosmos is a set of protocols and software (SDKs) designed to be deployed in separate yet interoperable networks and infrastructures by third parties
    • -
-

We want Waku to be decentralized to provide censorship resistance and privacy-preserving communication. -If each application has to deploy its own network, we will not achieve this goal. -Therefore, we aim Waku to be not only an open source set of protocols, but also a shared infrastructure that anyone can leverage to build applications on top, with some guarantees in terms of decentralization and anonymity. -This approach is closer in spirit to Ethereum than Cosmos. -Do note that, similarly to Ethereum, anyone is free to take Waku software and protocols and deploy their own network.

-

Yet, because of the difference in the fee model, the Waku Network is unlikely to be as unified as Ethereum's. -We currently assume that there will be separate gossipsub networks with different funding models. -Since there is no consensus on Waku, each individual operator can decide which network to support, enabling Waku to maintain its permission-less property.

-

Most likely, the Waku network will be heterogeneous, and node operators will choose the incentivization model they prefer.

-

Scalability and Discovery Protocols​

-

To enable scalability, the flow of messages in the Waku network will be divided in shards, -so that not every node has to forward every message of the whole network. -Discovery protocols will facilitate users connecting to the right nodes to receive the messages they are interested in.

-

Different shards could be subject to a variety of rate limiting techniques (globally, targeted to that shard or something in-between).

-

Marketplace protocols may also be developed to help operators understand how they can best support the network and where -their resources are most needed. However, we are still far from establishing or even assert that such a marketplace will be needed.

-

Open Problems​

-

Splitting traffic between shards reduces bandwidth consumption for every Waku Relay node. -This improvement increases the likelihood that users with home connections can participate and contribute to the gossipsub network without encountering issues.

-

However, it does not cap traffic. -There are still open problems regarding how to guarantee that someone can use Waku with lower Internet bandwidth or run critical services, such as a validation node, on the same connection.

-

We have several ongoing initiatives:

-
    -
  • Analyzing the Status Community protocol to confirm efficient usage of Waku [4]
    • -
  • Simulating the Waku Network to measure actual bandwidth usage [5]
    • -
  • Segregating chat messages from control and media messages [6]
    • -
-

The final solution will likely be a combination of protocols that reduce bandwidth usage or mitigate the risk of DOS attacks, providing flexibility for users and platforms to enable the best experience.

-

The Evolving Waku Network​

-

The definition of the "Waku Network" will likely change over time. In the near future, it will transition from a single -gossipsub network to a sharded set of networks unified by a common discovery layer. This change will promote scalability -and allow various payment models to coexist within the Waku ecosystem.

-

In conclusion, the future of Waku Network entails growth, incentivization, and heterogeneity while steadfastly -maintaining its core principles. As Waku continues to evolve, we expect it to accommodate a diverse range of use cases -and business models, all while preserving privacy, resisting censorship, avoiding surveillance, and remaining accessible -to devices with limited resources.

-

References​

-
    -
  1. WAKU2-RELAY-SHARDING
    2. -
  2. 57/STATUS-Simple-Scaling
    3. -
  3. RLN-V2
    4. -
  4. Scaling Status Communities: Potential Problems
    5. -
  5. Waku Network Testing
    6. -
  6. WAKU2-RELAY-SHARDING: Control Message Shards
    7. -
]]> - - Franck - - \ No newline at end of file diff --git a/rlog/authors/index.html b/rlog/authors/index.html index ac01ebe1..b180d05b 100644 --- a/rlog/authors/index.html +++ b/rlog/authors/index.html @@ -10,14 +10,14 @@ - - + +
Skip to main content

Authors

  • Circe

    1

  • Dean

    3

  • Franck

    3

  • Hanno Cornelius

    2

  • Daniel

    2

  • Oskar

    12

  • Richard

    1

  • s1fr0

    1

  • Sanaz

    1

  • Moudy

    4

  • Aaryamann

    3

  • Umar Farooq

    4

  • Marvin

    3

  • Aleksei Vambol

    1

  • BenPH

    1

  • Ivan

    1

  • Gabriel

    1

  • Vac

    1
+ ) .lsd-dropdown__trigger:focus .lsd-dropdown__option-label{-webkit-text-decoration:underline;text-decoration:underline;}.lsd-dropdown__label{display:block;}.lsd-dropdown__button-container{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;}.lsd-dropdown__trigger{width:100%;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;border:none;cursor:pointer;background:none;}.lsd-dropdown__trigger:focus{outline:none;}.lsd-dropdown__option-label{cursor:inherit;white-space:nowrap;overflow:hidden;text-overflow:ellipsis;}.lsd-dropdown__icons{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-ms-flex-pack:center;-webkit-justify-content:center;justify-content:center;gap:8px;}.lsd-dropdown__icon{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;}.lsd-dropdown__supporting-text{margin:6px 14px;}.lsd-dropdown--error .lsd-dropdown__option-label{-webkit-text-decoration:line-through;text-decoration:line-through;}.lsd-dropdown--disabled{opacity:0.34;cursor:initial;}.lsd-dropdown--large{width:208px;}.lsd-dropdown--large.lsd-dropdown--error{width:230px;}.lsd-dropdown--large .lsd-dropdown__label{margin:0 0 6px 18px;}.lsd-dropdown--large .lsd-dropdown__button-container{height:40px;}.lsd-dropdown--large .lsd-dropdown__trigger{padding:10px 0px 10px 18px;}.lsd-dropdown--large .lsd-dropdown__icons{padding:0px 14px;}.lsd-dropdown--medium{width:188px;}.lsd-dropdown--medium.lsd-dropdown--error{width:210px;}.lsd-dropdown--medium .lsd-dropdown__label{margin:0 0 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__button-container{height:32px;}.lsd-dropdown--medium .lsd-dropdown__trigger{padding:6px 0px 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__icons{padding:0px 12px;}.lsd-dropdown--small{width:164px;}.lsd-dropdown--small.lsd-dropdown--error{width:186px;}.lsd-dropdown--small .lsd-dropdown__label{margin:0 0 6px 12px;}.lsd-dropdown--small .lsd-dropdown__button-container{height:28px;}.lsd-dropdown--small .lsd-dropdown__trigger{padding:6px 0px 6px 12px;}.lsd-dropdown--small .lsd-dropdown__icons{padding:0px 10px;}.lsd-dropdown--outlined .lsd-dropdown__button-container{border:1px solid rgb(var(--lsd-border-primary));}.lsd-dropdown--underlined .lsd-dropdown__button-container{border:1px solid transparent;border-bottom:1px solid rgb(var(--lsd-border-primary));}
Skip to main content

Authors

  • Circe

    1

  • Dean

    3

  • Franck

    3

  • Hanno Cornelius

    2

  • Daniel

    2

  • Oskar

    12

  • Richard

    1

  • s1fr0

    1

  • Sanaz

    1

  • Moudy

    4

  • Aaryamann

    3

  • Umar Farooq

    4

  • Marvin

    3

  • Aleksei Vambol

    1

  • BenPH

    1

  • Ivan

    1

  • Gabriel

    1

  • Vac

    1

  • Ekaterina

    1
\ No newline at end of file diff --git a/rlog/building-privacy-protecting-infrastructure/index.html b/rlog/building-privacy-protecting-infrastructure/index.html index 66167ff7..b9196497 100644 --- a/rlog/building-privacy-protecting-infrastructure/index.html +++ b/rlog/building-privacy-protecting-infrastructure/index.html @@ -10,8 +10,8 @@ - - + +
Skip to main content

Decentralized Message Layer Security (De-MLS) with Waku

by
14 min read

This post introduces de-MLS, a decentralized variant of Message Layer Security (MLS) +that reimagines group messaging by replacing centralized delivery services with peer-to-peer protocols +while retaining strong guarantees such as forward secrecy (FS) and post-compromise security (PCS).

+ +

Introduction​

+

Secure Group Messaging (SGM) is resource-intensive when aiming for robust security features +like forward secrecy (FS) and post-compromise security (PCS).

+

One straightforward approach to SGM is a pairwise group chat, +where each pair of group members establishes a unique encryption key using Diffie-Hellman. +While this method ensures security, it falls short in terms of practicality:

+
    +
  • High storage requirements: Each participant must store encryption keys for every other participant.
    • +
  • Inefficient encryption: Each message must be encrypted separately for every participant, +leading to significant computational overhead.
    • +
  • Inefficient message storage and delivery: Each separately encrypted message must then be sent over the wire, +whatever this wire might be. Or stored in database.
    • +
  • Cumbersome group management: Adding or removing users and refreshing keys becomes +increasingly inefficient as the group grows.
    • +
+

One scalable for Secure Group Messaging (SGM) is Message Layer Security (MLS), as standardized in RFC 9420. +Leveraging TreeKEM, MLS organizes group members in a cryptographic tree structure, +where each participant is responsible for maintaining specific parts of the tree.

+

While MLS offers scalability and strong security guarantees, +its reliance on server-based delivery services poses limitations for fully decentralized environments.

+

In this post, we present the implementation details of the first version of Decentralized MLS (de-MLS) +which is an SGM protocol. De-MLS can serve groups that cannot rely on central servers, +such as journalists and activists seeking secure communication. +It is also well suited for DAOs, where Ethereum-based authentication can restrict access to members +holding a minimum ETH balance, and for NGOs or research consortia that prefer not to host their own servers while still +requiring end-to-end encrypted group messaging. Decentralized MLS (de-MLS) satisfies the following features:

+
    +
  • Decentralized
    • +
  • Scalable
    • +
  • End-to-end encrypted (E2EE)
    • +
  • FS and PCS provided
    • +
  • Ethereum authenticated
    • +
+

Background​

+

MLS​

+

The Message Layer Security (MLS) protocol offers scalable and secure group messaging protocol +by organizing participants into a cryptographic tree structure, +enabling efficient operations like adding or removing members with logarithmic time complexity +relative to the group size. MLS provides strong security guarantees, including FS and PCS.

+

MLS assumes that two services are provided:

+
    +
  • An Authentication Service (AS): It enables group members to +authenticate the credentials presented by other group members.
    • +
  • A Delivery Service (DS) that routes MLS messages among the +participants in the protocol in the correct order and manage the keyPackage of the users +where the keyPackage is the objects that provide some public information about a user.
    • +
+

Despite its scalability, MLS has a notable limitation: +it is inherently designed for server-based federated architectures for delivery service (DS), +even when the servers themselves don't need to be trusted. +To achieve a decentralized protocol, the functionality of DS must be reimagined +to eliminate reliance on a central server while preserving the protocol's security properties. +Thus, we proposed decentralized MLS (de-MLS), +leveraging Waku nodes as peer-to-peer communication protocols to eliminate reliance on centralized servers.

+

Lastly, MLS operates on an epoch-based model, +where group state changes (e.g., adding/removing users or key refreshes) occur between epochs +that are always required to be conducted by a single entity. +For example, if a user is removed in epoch E, +the rest of the group members generate a new key in epoch E + 1 by passing the new entropy. +The removed user cannot decrypt messages sent after epoch E + 1.

+

Waku​

+

Waku is a decentralized messaging protocol designed for secure and efficient communication in peer-to-peer networks. +It operates as a broadcast-based routing layer where content topics can be used to tag and filter messages. +Users join channels by subscribing to specific content topics, +which determine the scope and type of messages exchanged. +This enables flexible and efficient communication patterns in a decentralized environment.

+

de-MLS​

+

Decentralized MLS (de-MLS) is a peer-to-peer secure group messaging protocol +that can work with any delivery service (DS) meeting a minimal set of requirements. +In this post, we highlight its integration with Waku as the messaging protocol, +while emphasizing that de-MLS itself remains agnostic to the underlying DS. +Further technical details can be found in the de-MLS RFC.

+

Decentralization is achieved not only at the delivery service (DS) level +but also within the authentication service (AS). +Multiple special nodes named Steward in the group serve as authorized identities to authenticate users +before they join or are removed from the group transparently.

+

de-MLS provides two different user management configurations, both utilizing the Waku protocol for DS:

+
    +
  1. Single Steward: +
      +
    • A single authorized identity (Steward) manages the group, +including removing or adding users with agreement among users by a voting-based consensus.
      • +
    +
    2. +
  2. Multi-Steward: +
      +
    • Multiple Stewards have equal authority to add or remove users.
      • +
    • A consensus mechanism ensures consistency by resolving concurrent changes +within the same epoch and preventing possible conflicts. +In each epoch, all modifications are managed exclusively by a single Steward.
      • +
    +
    3. +
+

Note: We chose the term Steward to reflect the role of transparently coordinating and organizing passengers at stations, much like Stewards do in transit systems.

+

In multi-Steward settings, de-MLS requires a consensus among Stewards +that have equal rights in the group since changes in an epoch in MLS are required +to be conducted by a single identity, that is the Steward.

+

For the consensus integration, ongoing research explores two promising approaches:

+
    +
  1. On-chain consensus mechanisms: +Outsourcing consensus to a smart contract solution for transparent and immutable agreement.
    2. +
  2. Off-chain consensus mechanisms: +Utilizing off-chain consensus protocols to design efficient, decentralized protocols.
    3. +
+

Waku Integration​

+

Waku integration is a crucial step in the construction of de-MLS, +aiming to replace traditional client-server communication with decentralized messaging. +The specifics of Waku integration will be detailed in a separate RFC; +for now, our main priority is the de-MLS RFC.

+

The main challenge in this transition is transforming the centralized Delivery Service (DS) +into a decentralized equivalent, which performs two essential functions:

+
    +
  1. Message Delivery and Ordering: +The DS is responsible not only for delivering messages to the correct recipients, +but also for preserving the correct order of these messages, which is critical for the consistency of group state.
    2. +
  2. Key Package Management: +The DS manages key packages, which are essential for adding members securely to a group.
    3. +
+

To maintain a truly decentralized architecture, +key packages cannot be stored in a centralized location. +Initially, we considered using a smart contract (SC) as a decentralized substitute for server-side key package storage. +However, this approach proved impractical. +Blockchains are immutable by design—once data is written, it cannot be fully removed. +This contradicts a core requirement of MLS: each key package must be used exactly once and then deleted, +to prevent replay or reuse attacks. +Instead, our solution is to require users to actively provide their key packages upon request, +allowing validation at the moment of use without persistent storage. +While this approach may lose some benefits of asynchronicity, +we plan to address this in the future by introducing store nodes that can temporarily hold key packages. +This ensures both compliance with MLS's security model and alignment with decentralized system principles.

+

Flow​

+

The flow section explains the processes that +when a user wants to join a group in both Steward and users side also their interactions. +The flow of de-MLS is as follows:

+

Figure 1

+

1. Steward joins the welcome topic​

+

The welcome topic is a topic created and monitored by the Steward for a specific secure messaging group, +allowing any Waku node to subscribe permissionlessly. +Being in the welcome topic does not imply group membership, +it acts as a waiting room where users can send their key material, +which the Steward listens for and processes before granting access to the secure group.

+

2. Group initialization​

+

Steward initalizes a group with parameters such as cipher suite and group ID.

+

3. Emitting Group Anouncement (GA) by Steward​

+

Steward creates group announcement (GA) periodically to the welcome channel +that the users can find the who the Steward is. +This will be important for the next step.

+

4. User joins the welcome topic​

+

As first, the users who wants to be part of the decentralized MLS should subscribe the welcome channel. +Then user can find the group name and also corresponding GA message from Steward. +This GA message helps the user to create a valid keyPackages which define in section 10 +in RFC9420 for the group.

+

5. User creates its key package​

+

User creates the keyPackage and encrypt by public key of the Steward then send it to the Steward. +Since the message is encrypted, stay secure though the welcome (permissionless) topic.

+

6. Steward receives the User's key package​

+

Steward receives the user's keyPackage and decrypt it. +After decrypted, Steward also verifies the validity of the keyPackage by signature verification. +If the keyPackage is not valid, the Steward just drops the message, +otherwise it moves to the next step which is proposal creation.

+

7. Creation of Voting proposals​

+

Voting proposals are special MLS application messages that may come from any participant, including the Steward. +In this context, any member can create a proposal corresponding to the user’s keyPackage. +In regular MLS, proposals are automatically converted into commit messages, +which can change the structure of the tree. However, in de-MLS, since the process is decentralized, +proposals must be voted on before being converted into a commitment.

+

8. Voting for proposal​

+

Voting applies decentralization by protecting small groups can control. +Therefore, proposals must be voted on before committing. +The consensus mechanism should be a lightweight consensus that cannot be a bottleneck for treeKEM scalability. +Basically, the consensus returns the binary result for a given proposal. +If voting result is NO, the proposal is dropped; otherwise, the Steward transforms it into an MLS proposal. +MLS proposal message is a distinct type of MLS application message, +where the Steward attaches the voting result instead of directly releasing a commit message.

+

9. Creating commit message​

+

Commit messages are the messages that start new epochs. +They include key and tree material that existing members can use to generate the new state of the tree.

+

After Steward gets the YES from consensus, Steward creates commit messages +that injects new entropy for the existing group members.

+

10. Sending messages​

+

After Steward creates and then sends two messages:

+
    +
  1. Commit message informs existing group member to update their key +to align with the new member’s key for the upcoming epoch.
    2. +
  2. The welcome message informs the newly joined user to generate a group key +that matches the key existing members will use in the upcoming epoch.
    3. +
+

Although existing users had different group keys in the previous epoch and the new user had none, +the Steward message ensures that both existing and new users converge on the same group key in the next epoch.

+

11. Applying welcome message​

+

User can generate the next epoch group key by using the welcome message as well as +existing users extract the same groupKey by using commit messages.

+

The commit message helps existing members generate the next group key Gk+1, +while the welcome message helps the newly joining user generate the same Gk+1. +This provides two important security properties:

+
    +
  1. +

    Forward Secrecy (FS): +The new user cannot read previous messages since they were encrypted with the old key Gk

    +
    2. +
  2. +

    Post-Compromise Security (PCS): +If a user is removed from the group, +they cannot read future messages since those messages will be encrypted with the new key Gk+1

    +
    3. +
+

Benchmark​

+

This section presents the performance evaluation of de-MLS. +One of the key advantages of the MLS protocol is its efficiency, +as it eliminates the need for pairwise message exchanges between all participants. +Instead, the decentralized DS enables the addition of new participants by sending only two messages to the group: +a commit message and a welcome message. +However, despite this advantage, the protocol does have certain bottlenecks, which are as follows:

+
    +
  • Firstly, the Steward must receive the key packages from each member wishing to join the group. +This process requires sequential message exchanges and involves computationally intensive tasks such as encryption, +decryption, and digital signature verification. +Even when multiple users are added to the group simultaneously, the process is essentially sequential. +The tree structure is updated one user at a time, +followed by sending the final commit message to the existing group members +and a single welcome message to the new members.
    • +
  • Secondly adding a member to a group requires rebuilding the tree and computing new keys.
    • +
+

The following measurements were made as follows:

+
    +
  1. The time required for the entire sequence of receiving a user key package is presented here. +This includes generating the Steward key, creating messages with signatures and encryption, +and processing these messages.
    2. +
+

Share Key Package - 1.8395 ms

+

Note that these measurements do not account for the time taken to forward messages.

+
    +
  1. The time required for creating the commit and welcome message +from a ready-made package bunches is shown in this table.
    2. +
+
Group Size (by users)Time
101.8662 ms
10014.124 ms
500121.85 ms
1000412.39 ms
5000~ 15-20 s
10000~ 1-1.5 min
+

The tests were conducted on the following configuration: +Apple M3 Pro @ 4.05GHz and 12-Core CPU/18-Core GPU.

+

Here, the network latency and the time taken by users to apply the received commits are also excluded. +These aspects are planned to be measured and evaluated in future work.

+

Potential drawbacks and countermeasures​

+

Since de-MLS replace the servers by P2P, we could lose some good features of servers based MLS. +In this section we present the potential drawbacks and possible countermeasures of de-MLS.

+
    +
  • Offline users: keyPackages are provided by the users directly without any storing, +this is required each user must be online for joining to a group. +
      +
    • We can consider to use Waku sync nodes +that are nodes has storing ability for a temporary storing of keyPackages.
      • +
    +
    • +
  • DoS attack to Steward: Steward is known in welcome message from periodic group announcement message +so Steward can be targeted for DoS attack. +
      +
    • As always we consider to use Rate-Limiting Nullifier (RLN) with Waku to protect network from spam.
      • +
    +
    • +
  • Message loss or delay : Because of P2P and consensus settings, message can be lost or delayed., +
      +
    • We can integrate reliability mechanisms to Waku such as +scalable data sync (SDS)
      • +
    • Consensus mechanism requires to provide liveness property against offline nodes, for example, +it may provides default YES or NO options for a silent users who do not vote.
      • +
    +
    • +
  • Enchanced authentication +
      +
    • Ethereum authentication could be inefficient. +We can configure the authentication mechanism for example asking minimum balance or etc.
      • +
    +
    • +
+

Conclusion​

+

To summarize, the approach to solving decentralized DS tasks with Waku +can be outlined as shown in the comparison table:

+
FeatureMLSde-MLS
Message DistributionMessages are sent from the server to clientsMessages are sent by publishing/subscribing to pub-sub topics
Commit Message HandlingRelies on a serverRelies on a consensus and transparent Steward
Key Package ManagementKey packages are stored and distributed by the serverKey packages are provided by the users themselves
+

Future Work​

+

In the next iterations, the implementations are planned as following:

+
    +
  • Dual-Consensus Multi-Steward Support: One consensus mechanism selects an Steward from all users, +while a second governs group decisions among the elected Stewards
    • +
  • Consensus mechanism for handling concurrent changes within the same epoch
    • +
  • Key rotation support
    • +
  • Benchmarking for the multi-Steward configuration including the network time
    • +
+

References​

+
+ + \ No newline at end of file diff --git a/rlog/device-pairing-in-js-waku-and-go-waku/index.html b/rlog/device-pairing-in-js-waku-and-go-waku/index.html index 225942e6..3037f306 100644 --- a/rlog/device-pairing-in-js-waku-and-go-waku/index.html +++ b/rlog/device-pairing-in-js-waku-and-go-waku/index.html @@ -10,8 +10,8 @@ - - + +
Skip to main content

Research Blog

Blog

Scaling libp2p GossipSub for Large Messages: An Evaluation of Performance Improvement Proposals

by
16 min read

The original GossipSub design emphasizes robustness, with less focus on message sizes. + ) .lsd-dropdown__trigger:focus .lsd-dropdown__option-label{-webkit-text-decoration:underline;text-decoration:underline;}.lsd-dropdown__label{display:block;}.lsd-dropdown__button-container{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;}.lsd-dropdown__trigger{width:100%;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;border:none;cursor:pointer;background:none;}.lsd-dropdown__trigger:focus{outline:none;}.lsd-dropdown__option-label{cursor:inherit;white-space:nowrap;overflow:hidden;text-overflow:ellipsis;}.lsd-dropdown__icons{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-ms-flex-pack:center;-webkit-justify-content:center;justify-content:center;gap:8px;}.lsd-dropdown__icon{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;}.lsd-dropdown__supporting-text{margin:6px 14px;}.lsd-dropdown--error .lsd-dropdown__option-label{-webkit-text-decoration:line-through;text-decoration:line-through;}.lsd-dropdown--disabled{opacity:0.34;cursor:initial;}.lsd-dropdown--large{width:208px;}.lsd-dropdown--large.lsd-dropdown--error{width:230px;}.lsd-dropdown--large .lsd-dropdown__label{margin:0 0 6px 18px;}.lsd-dropdown--large .lsd-dropdown__button-container{height:40px;}.lsd-dropdown--large .lsd-dropdown__trigger{padding:10px 0px 10px 18px;}.lsd-dropdown--large .lsd-dropdown__icons{padding:0px 14px;}.lsd-dropdown--medium{width:188px;}.lsd-dropdown--medium.lsd-dropdown--error{width:210px;}.lsd-dropdown--medium .lsd-dropdown__label{margin:0 0 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__button-container{height:32px;}.lsd-dropdown--medium .lsd-dropdown__trigger{padding:6px 0px 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__icons{padding:0px 12px;}.lsd-dropdown--small{width:164px;}.lsd-dropdown--small.lsd-dropdown--error{width:186px;}.lsd-dropdown--small .lsd-dropdown__label{margin:0 0 6px 12px;}.lsd-dropdown--small .lsd-dropdown__button-container{height:28px;}.lsd-dropdown--small .lsd-dropdown__trigger{padding:6px 0px 6px 12px;}.lsd-dropdown--small .lsd-dropdown__icons{padding:0px 10px;}.lsd-dropdown--outlined .lsd-dropdown__button-container{border:1px solid rgb(var(--lsd-border-primary));}.lsd-dropdown--underlined .lsd-dropdown__button-container{border:1px solid transparent;border-bottom:1px solid rgb(var(--lsd-border-primary));}

Research Blog

Blog

Decentralized Message Layer Security (De-MLS) with Waku

by
14 min read

This post introduces de-MLS, a decentralized variant of Message Layer Security (MLS) +that reimagines group messaging by replacing centralized delivery services with peer-to-peer protocols +while retaining strong guarantees such as forward secrecy (FS) and post-compromise security (PCS).

Scaling libp2p GossipSub for Large Messages: An Evaluation of Performance Improvement Proposals

by
16 min read

The original GossipSub design emphasizes robustness, with less focus on message sizes. However, emerging use cases—such as Ethereum's EIP-4844 and data availability sampling (DAS) require rapid propagation of high data volumes, often in the form of large messages. @@ -40,6 +42,6 @@ place where Zerokit comes through, fast and efficient, ready to face the world.

Nim in Logos - 1st Edition

by
7 min read

Welcome to the first edition of Nim in Logos — a newsletter covering major Nim features from Logos' perspective.

If you have comments or suggestions, feel free to reach out to the authors directly or start a thread in the Logos Discord server.

+as the components of affine permutation layers of P-SP-networks.

\ No newline at end of file diff --git a/rlog/introducing-nwaku/index.html b/rlog/introducing-nwaku/index.html index 65a2d55e..15fbd5b9 100644 --- a/rlog/introducing-nwaku/index.html +++ b/rlog/introducing-nwaku/index.html @@ -10,8 +10,8 @@ - - + +
Skip to main content

Research Blog

Blog
+ ) .lsd-dropdown__trigger:focus .lsd-dropdown__option-label{-webkit-text-decoration:underline;text-decoration:underline;}.lsd-dropdown__label{display:block;}.lsd-dropdown__button-container{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;}.lsd-dropdown__trigger{width:100%;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;border:none;cursor:pointer;background:none;}.lsd-dropdown__trigger:focus{outline:none;}.lsd-dropdown__option-label{cursor:inherit;white-space:nowrap;overflow:hidden;text-overflow:ellipsis;}.lsd-dropdown__icons{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-ms-flex-pack:center;-webkit-justify-content:center;justify-content:center;gap:8px;}.lsd-dropdown__icon{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;}.lsd-dropdown__supporting-text{margin:6px 14px;}.lsd-dropdown--error .lsd-dropdown__option-label{-webkit-text-decoration:line-through;text-decoration:line-through;}.lsd-dropdown--disabled{opacity:0.34;cursor:initial;}.lsd-dropdown--large{width:208px;}.lsd-dropdown--large.lsd-dropdown--error{width:230px;}.lsd-dropdown--large .lsd-dropdown__label{margin:0 0 6px 18px;}.lsd-dropdown--large .lsd-dropdown__button-container{height:40px;}.lsd-dropdown--large .lsd-dropdown__trigger{padding:10px 0px 10px 18px;}.lsd-dropdown--large .lsd-dropdown__icons{padding:0px 14px;}.lsd-dropdown--medium{width:188px;}.lsd-dropdown--medium.lsd-dropdown--error{width:210px;}.lsd-dropdown--medium .lsd-dropdown__label{margin:0 0 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__button-container{height:32px;}.lsd-dropdown--medium .lsd-dropdown__trigger{padding:6px 0px 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__icons{padding:0px 12px;}.lsd-dropdown--small{width:164px;}.lsd-dropdown--small.lsd-dropdown--error{width:186px;}.lsd-dropdown--small .lsd-dropdown__label{margin:0 0 6px 12px;}.lsd-dropdown--small .lsd-dropdown__button-container{height:28px;}.lsd-dropdown--small .lsd-dropdown__trigger{padding:6px 0px 6px 12px;}.lsd-dropdown--small .lsd-dropdown__icons{padding:0px 10px;}.lsd-dropdown--outlined .lsd-dropdown__button-container{border:1px solid rgb(var(--lsd-border-primary));}.lsd-dropdown--underlined .lsd-dropdown__button-container{border:1px solid transparent;border-bottom:1px solid rgb(var(--lsd-border-primary));}
Skip to main content

Research Blog

Blog
\ No newline at end of file diff --git a/rlog/page/3/index.html b/rlog/page/3/index.html index cf058cc4..7890b293 100644 --- a/rlog/page/3/index.html +++ b/rlog/page/3/index.html @@ -3,25 +3,25 @@ -Research Blog | Vac Research +Research Blog | Vac Research - - + +
Skip to main content

Research Blog

Blog

Waku for All Decentralized Applications and Infrastructures

by
7 min read

Waku is an open communication protocol and network. Decentralized apps and infrastructure can use Waku for their + ) .lsd-dropdown__trigger:focus .lsd-dropdown__option-label{-webkit-text-decoration:underline;text-decoration:underline;}.lsd-dropdown__label{display:block;}.lsd-dropdown__button-container{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;}.lsd-dropdown__trigger{width:100%;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;border:none;cursor:pointer;background:none;}.lsd-dropdown__trigger:focus{outline:none;}.lsd-dropdown__option-label{cursor:inherit;white-space:nowrap;overflow:hidden;text-overflow:ellipsis;}.lsd-dropdown__icons{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-ms-flex-pack:center;-webkit-justify-content:center;justify-content:center;gap:8px;}.lsd-dropdown__icon{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;}.lsd-dropdown__supporting-text{margin:6px 14px;}.lsd-dropdown--error .lsd-dropdown__option-label{-webkit-text-decoration:line-through;text-decoration:line-through;}.lsd-dropdown--disabled{opacity:0.34;cursor:initial;}.lsd-dropdown--large{width:208px;}.lsd-dropdown--large.lsd-dropdown--error{width:230px;}.lsd-dropdown--large .lsd-dropdown__label{margin:0 0 6px 18px;}.lsd-dropdown--large .lsd-dropdown__button-container{height:40px;}.lsd-dropdown--large .lsd-dropdown__trigger{padding:10px 0px 10px 18px;}.lsd-dropdown--large .lsd-dropdown__icons{padding:0px 14px;}.lsd-dropdown--medium{width:188px;}.lsd-dropdown--medium.lsd-dropdown--error{width:210px;}.lsd-dropdown--medium .lsd-dropdown__label{margin:0 0 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__button-container{height:32px;}.lsd-dropdown--medium .lsd-dropdown__trigger{padding:6px 0px 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__icons{padding:0px 12px;}.lsd-dropdown--small{width:164px;}.lsd-dropdown--small.lsd-dropdown--error{width:186px;}.lsd-dropdown--small .lsd-dropdown__label{margin:0 0 6px 12px;}.lsd-dropdown--small .lsd-dropdown__button-container{height:28px;}.lsd-dropdown--small .lsd-dropdown__trigger{padding:6px 0px 6px 12px;}.lsd-dropdown--small .lsd-dropdown__icons{padding:0px 10px;}.lsd-dropdown--outlined .lsd-dropdown__button-container{border:1px solid rgb(var(--lsd-border-primary));}.lsd-dropdown--underlined .lsd-dropdown__button-container{border:1px solid transparent;border-bottom:1px solid rgb(var(--lsd-border-primary));}

Research Blog

Blog

Waku for All Decentralized Applications and Infrastructures

by
7 min read

Waku is an open communication protocol and network. Decentralized apps and infrastructure can use Waku for their communication needs. It is designed to enable dApps and decentralized infrastructure projects to have secure, private, scalable communication. Waku is available in several languages and platforms, from Web to mobile to desktop to cloud. Initially, We pushed Waku adoption to the Web ecosystem, we learned that Waku is usable in a variety of complex applications -and infrastructure projects. We have prioritized our effort to make Waku usable on various platforms and environments.

Building Privacy-Protecting Infrastructure

by
19 min read

What is privacy-protecting infrastructure? Why do we need it and how we can build it? We'll look at Waku, the communication layer for Web3. We'll see how it uses ZKPs to incentivize and protect the Waku network. We'll also look at Zerokit, a library that makes it easier to use ZKPs in different environments. After reading this, I hope you'll better understand the importance of privacy-protecting infrastructure and how we can build it.

Introducing nwaku

by
11 min read

Introducing nwaku, a Nim-based Waku v2 client, including a summary of recent developments and preview of current and future focus areas.

+and infrastructure projects. We have prioritized our effort to make Waku usable on various platforms and environments.

Building Privacy-Protecting Infrastructure

by
19 min read

What is privacy-protecting infrastructure? Why do we need it and how we can build it? We'll look at Waku, the communication layer for Web3. We'll see how it uses ZKPs to incentivize and protect the Waku network. We'll also look at Zerokit, a library that makes it easier to use ZKPs in different environments. After reading this, I hope you'll better understand the importance of privacy-protecting infrastructure and how we can build it.

Introducing nwaku

by
11 min read

Introducing nwaku, a Nim-based Waku v2 client, including a summary of recent developments and preview of current and future focus areas.

\ No newline at end of file diff --git a/rlog/page/4/index.html b/rlog/page/4/index.html index 2a4dd95f..4c2e2a50 100644 --- a/rlog/page/4/index.html +++ b/rlog/page/4/index.html @@ -3,21 +3,21 @@ -Research Blog | Vac Research +Research Blog | Vac Research - - + +
Skip to main content

Research Blog

Blog

Privacy-preserving p2p economic spam protection in Waku v2

by
21 min read

This post is going to give you an overview of how spam protection can be achieved in Waku Relay through rate-limiting nullifiers. We will cover a summary of spam-protection methods in centralized and p2p systems, and the solution overview and details of the economic spam-protection method. The open issues and future steps are discussed in the end.

Waku v2 Update

by
8 min read

A research log. Read on to find out what is going on with Waku v2, a messaging protocol. What has been happening? What is coming up next?

From Kademlia to Discv5

by
9 min read

A quick history of discovery in peer-to-peer networks, along with a look into discv4 and discv5, detailing what they are, how they work and where they differ.

Waku Update

by
6 min read

A research log. What's the current state of Waku? How many users does it support? What are the bottlenecks? What's next?

+ ) .lsd-dropdown__trigger:focus .lsd-dropdown__option-label{-webkit-text-decoration:underline;text-decoration:underline;}.lsd-dropdown__label{display:block;}.lsd-dropdown__button-container{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;}.lsd-dropdown__trigger{width:100%;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;border:none;cursor:pointer;background:none;}.lsd-dropdown__trigger:focus{outline:none;}.lsd-dropdown__option-label{cursor:inherit;white-space:nowrap;overflow:hidden;text-overflow:ellipsis;}.lsd-dropdown__icons{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-ms-flex-pack:center;-webkit-justify-content:center;justify-content:center;gap:8px;}.lsd-dropdown__icon{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;}.lsd-dropdown__supporting-text{margin:6px 14px;}.lsd-dropdown--error .lsd-dropdown__option-label{-webkit-text-decoration:line-through;text-decoration:line-through;}.lsd-dropdown--disabled{opacity:0.34;cursor:initial;}.lsd-dropdown--large{width:208px;}.lsd-dropdown--large.lsd-dropdown--error{width:230px;}.lsd-dropdown--large .lsd-dropdown__label{margin:0 0 6px 18px;}.lsd-dropdown--large .lsd-dropdown__button-container{height:40px;}.lsd-dropdown--large .lsd-dropdown__trigger{padding:10px 0px 10px 18px;}.lsd-dropdown--large .lsd-dropdown__icons{padding:0px 14px;}.lsd-dropdown--medium{width:188px;}.lsd-dropdown--medium.lsd-dropdown--error{width:210px;}.lsd-dropdown--medium .lsd-dropdown__label{margin:0 0 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__button-container{height:32px;}.lsd-dropdown--medium .lsd-dropdown__trigger{padding:6px 0px 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__icons{padding:0px 12px;}.lsd-dropdown--small{width:164px;}.lsd-dropdown--small.lsd-dropdown--error{width:186px;}.lsd-dropdown--small .lsd-dropdown__label{margin:0 0 6px 12px;}.lsd-dropdown--small .lsd-dropdown__button-container{height:28px;}.lsd-dropdown--small .lsd-dropdown__trigger{padding:6px 0px 6px 12px;}.lsd-dropdown--small .lsd-dropdown__icons{padding:0px 10px;}.lsd-dropdown--outlined .lsd-dropdown__button-container{border:1px solid rgb(var(--lsd-border-primary));}.lsd-dropdown--underlined .lsd-dropdown__button-container{border:1px solid transparent;border-bottom:1px solid rgb(var(--lsd-border-primary));}
Skip to main content

Research Blog

Blog

Privacy-preserving p2p economic spam protection in Waku v2

by
21 min read

This post is going to give you an overview of how spam protection can be achieved in Waku Relay through rate-limiting nullifiers. We will cover a summary of spam-protection methods in centralized and p2p systems, and the solution overview and details of the economic spam-protection method. The open issues and future steps are discussed in the end.

Waku v2 Update

by
8 min read

A research log. Read on to find out what is going on with Waku v2, a messaging protocol. What has been happening? What is coming up next?

From Kademlia to Discv5

by
9 min read

A quick history of discovery in peer-to-peer networks, along with a look into discv4 and discv5, detailing what they are, how they work and where they differ.

Waku Update

by
6 min read

A research log. What's the current state of Waku? How many users does it support? What are the bottlenecks? What's next?

\ No newline at end of file diff --git a/rlog/page/5/index.html b/rlog/page/5/index.html index 89273e73..e2f7f19f 100644 --- a/rlog/page/5/index.html +++ b/rlog/page/5/index.html @@ -3,21 +3,21 @@ -Research Blog | Vac Research +Research Blog | Vac Research - - + +
Skip to main content

Research Blog

Blog

Vac - A Rough Overview

by
6 min read

Vac is a modular peer-to-peer messaging stack, with a focus on secure messaging. Overview of terms, stack and open problems.

+ ) .lsd-dropdown__trigger:focus .lsd-dropdown__option-label{-webkit-text-decoration:underline;text-decoration:underline;}.lsd-dropdown__label{display:block;}.lsd-dropdown__button-container{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;}.lsd-dropdown__trigger{width:100%;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:justify;-webkit-justify-content:space-between;justify-content:space-between;border:none;cursor:pointer;background:none;}.lsd-dropdown__trigger:focus{outline:none;}.lsd-dropdown__option-label{cursor:inherit;white-space:nowrap;overflow:hidden;text-overflow:ellipsis;}.lsd-dropdown__icons{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-ms-flex-pack:center;-webkit-justify-content:center;justify-content:center;gap:8px;}.lsd-dropdown__icon{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;}.lsd-dropdown__supporting-text{margin:6px 14px;}.lsd-dropdown--error .lsd-dropdown__option-label{-webkit-text-decoration:line-through;text-decoration:line-through;}.lsd-dropdown--disabled{opacity:0.34;cursor:initial;}.lsd-dropdown--large{width:208px;}.lsd-dropdown--large.lsd-dropdown--error{width:230px;}.lsd-dropdown--large .lsd-dropdown__label{margin:0 0 6px 18px;}.lsd-dropdown--large .lsd-dropdown__button-container{height:40px;}.lsd-dropdown--large .lsd-dropdown__trigger{padding:10px 0px 10px 18px;}.lsd-dropdown--large .lsd-dropdown__icons{padding:0px 14px;}.lsd-dropdown--medium{width:188px;}.lsd-dropdown--medium.lsd-dropdown--error{width:210px;}.lsd-dropdown--medium .lsd-dropdown__label{margin:0 0 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__button-container{height:32px;}.lsd-dropdown--medium .lsd-dropdown__trigger{padding:6px 0px 6px 14px;}.lsd-dropdown--medium .lsd-dropdown__icons{padding:0px 12px;}.lsd-dropdown--small{width:164px;}.lsd-dropdown--small.lsd-dropdown--error{width:186px;}.lsd-dropdown--small .lsd-dropdown__label{margin:0 0 6px 12px;}.lsd-dropdown--small .lsd-dropdown__button-container{height:28px;}.lsd-dropdown--small .lsd-dropdown__trigger{padding:6px 0px 6px 12px;}.lsd-dropdown--small .lsd-dropdown__icons{padding:0px 10px;}.lsd-dropdown--outlined .lsd-dropdown__button-container{border:1px solid rgb(var(--lsd-border-primary));}.lsd-dropdown--underlined .lsd-dropdown__button-container{border:1px solid transparent;border-bottom:1px solid rgb(var(--lsd-border-primary));}
Skip to main content

Research Blog

Blog

Vac - A Rough Overview

by
6 min read

Vac is a modular peer-to-peer messaging stack, with a focus on secure messaging. Overview of terms, stack and open problems.

\ No newline at end of file diff --git a/rlog/presenting-js-waku/index.html b/rlog/presenting-js-waku/index.html index beda78f8..86abccdd 100644 --- a/rlog/presenting-js-waku/index.html +++ b/rlog/presenting-js-waku/index.html @@ -10,8 +10,8 @@ - - + +