Posting images I found on my laptop that are regarding the daily aggregator when I was thinking about it.
Here’s an example of the simplest daily aggregator.
It’s a straightforward centralized implementation. It works well and is simple to implement. The main issue would be if the service is silently forced to keep logs of the data. This means you either end up shutting it down (if you’re allowed to?) or keep leaking data to some party. Months ago, I was thinking of ways to resolve this and I think the pre-block cut-through is interesting in that it is able to lose information through transactions. Here’s one example that I have already mentioned, but I don’t believe I’ve shared it as a picture.
With this scheme, even if the daily aggregator is forced to log transactions, it can’t reveal the input/output links because in the end, it only knows which inputs and kernels belonged together because the transaction that is broadcasted at the end has completely different outputs than the daily aggregator saw. Similarly the service to which the daily aggregator sends data to can’t tell the links. None of the two services involved now knows any input/output links if everything goes through so they can’t give useful information. Only daily aggregator could do that if it broadcasted early, but this could get caught because we know which outputs we expect on the chain. They would both need to be forced to log by and provide the data to the same entity. What’s good here is that this can horizontally scale, meaning you can have N services in this aggregator chain and each would replace all the outputs, which means that if the whole chain goes through, if they don’t collude, the “attacker” would need to get the logs from all of the services on the chain. Likewise, if any service was dishonest and would broadcast early, it would be possible to see this.
Note: In case of more than 1 such service, you’d do onion encryption to encrypt data for all the services in the chain.
There are of course downsides, like what happens if they are offline? Perhaps distributing these across the globe so that we are not vulnerable to regulations in a single country would be good. There’s also a problem of how to replace a service, where do we get the public keys to encrypt for? In theory, this could be a public endpoint that a wallet would query to get the public keys to encrypt the data. This makes it easy to update (though has other downsides).
TLDR: it’s possible to make a scheme where if the aggregated tx goes through a chain of N static nodes, it is guaranteed that no single node that saw the aggregated tx knows the input/output links if at least one node was honest. The nodes can log the tx if needed so it’s safe in this way for the nodes. Similarly, users get their privacy so they are protected.
The takeaway here is that it might be interesting to think of other schemes that use the pre-block cut-through to achieve some other interesting properties.