From 4abffc4a5f229973b4a5920a1277114776c1ac68 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Viktor=20Tr=C3=B3n?= Date: Sat, 8 Nov 2025 09:52:57 +0100 Subject: [PATCH 1/2] Add SWIP 42: MOCs for efficient notifications Introduces the Mined Owner Chunk (MOC) concept for efficient notifications in Swarm architecture, detailing specifications, rationale, and implementation notes. --- SWIPs/swip-MOC.md | 132 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 SWIPs/swip-MOC.md diff --git a/SWIPs/swip-MOC.md b/SWIPs/swip-MOC.md new file mode 100644 index 0000000..141ee76 --- /dev/null +++ b/SWIPs/swip-MOC.md @@ -0,0 +1,132 @@ +--- +SWIP: 42 +title: MOC - Mined Owner Chunk - for efficient notifications +author: Bálint Újvári <@bosi95>, Viktor Tron <@zelig> +discussions-to: https://discord.com/channels/799027393297514537/1239813439136993280 +status: Draft +type: +created: 2025-11-04 +--- + +# Mined Owner Chunks + +## Abstract + +Mined Owner Chunks are Single Owner Chunks (SOC) with a fixed part (ID or owner) and an ephemeral part +(owner or ID) mined so that the SOC address falls into a particular target neighbouhood. This SwIP +introduces the concept as a vehicle for robust _notifications_. The properqooo e ooogg g vejggggqe + +## Motivation + +A major deficiency of the current Swarm architecture is that already explored communication modalities that could in principle serve as notifications, have their respective drawbacks either in terms of their excessive resource needs, or lacking service guarantees: + +- outbox feeds: + - require constant polling, so they also both process- and bandwidth-inefficient + (depending on the the polling period mainly) +- PSS, which is the trojan chunk allowing zero-leak comms: + - requires real-time mining by the sender, per message + - therefore it is slow and CPU inefficient (exponential in the target depth). + - while inheretly imcentivised as well as async, +- gSOCs are both difficult to interpret and at the same time, + - require recipient in the same address + - attaches multiple nessages to the same SOC + - address is fully specified + - and node must be closest node to be pushed + - therefore both leaks the identity as well as attackable + - impossible to retrieve outside the neighbourhood + +## Specification + +### Concepts + +- Target neighbourhood: indentified by an overlay prefix specified similar to nonce mining. +- Target neighbourhood overlay prefix: +- Mined owner: +- Mined ID: + +### Variants + +#### Mined ID Chunk (MICs) + +#### Mined Owner Chunks (MOCs) + +### API + +The notification service API needs to provide send API endpoint as well as a receive API endpoint which allows setting up websocket push notifications for input parameters. + +#### Sender API + +#### Receiver API + +### Identity management + +## Rationale + +The rationale behind this n + +### Premineble + +No sending delay because the address can be premined + +### Content neutral + +the same address can be associated with arbitrary content + +### Encryption + +like pss envelope using the mined address as the ephemeral one in el-gamal. + +### Async deliverability + +As MOC address is preminable, even same sender multiple messages can be distinct chunks +which automatically synchronise with pull-sync. + +#### Undermining attack + +Due to pull-sync syncing, if it is switched on, no chunk is missed by the recipient. +This is in contrast the earlier concept of GSOCs with no pull-syncing support +needs to rely on push syncing for delivery. Since push syncing can only guarantee +the delivery to the node closest to the address, adversaries can just mine an overlay +that is even closer to the full gsoc address than the intended recipient; in case the delivery path of a GSOC chunk +does not touch the recipient, is able to deny and withhold the chunk. + +#### non local recipient +if the target overlay prefix published by the recipient is $d$-bit long +($d>=D_s$, greater than the storage depth), then every MOC message falls into +the neighbourhood designated by target overlay (prefix). +But if the overlay prefix ($PO(addr(MOC),oprx_R$) +matches the recipient address only $m$-bits ($m=d$ of any of the full nodes in the appropriate target NH +the neighbourhood. + +If no historical messages are expected, then pull live syncing is sufficient. + +#### Syncing past messages + +Since MOCs are just SOCs, receiver can receive past messages via historical pull-syncing. + +#### Privacy +Importantly, this allows any neighbourhood to serve as a proxy while recipients to be located basically anywhere in the network and still efficiently get the nessages delivered to them in their PO bin $m$. From the proxy nodes' perspective, if $m< Date: Mon, 10 Nov 2025 15:56:33 +0100 Subject: [PATCH 2/2] Initial plan (#81) Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>