A few questions about the system just digging into it ;)

[BrandtH22]

• Verification process, when does the verification occur?? (having this occur too often would effectively be DoSing the operators but too little and uptime is not really monitored)

• Uptime and latency, aside from the verification process does this system have a means to verify uptime and latency? (if not then sponsors would be paying for poor data management/retention which is not ideal)

• Proxies / multi-network setups, aside from ip de-dup how does the system prevent a malicious actor from running multiple instances of the dig node against a single directory on their system? (ex. I can setup my device to have two or more IP addresses and isolate two different dig nodes that store the mirrored data in the same location, since the data in each mirror is identical there is no way to determine that my two dig nodes are actually using the same data files during verification. Potential solution would be to have mirrors create a hash or signature unique to them and store it within the data to be verified but even this could likely be emulated by a modified dig node by adding the hash/signature during the verification request. Note this is the concept that makes chia's PoS so unique.)

• Why do node mirrors have to stake but sponsors do not?? It seems like sponsors should be required to stake x epochs worth of funds so that operators will always be paid rather than relying on trust of the sponsors. Just made it to the escrow vaults part that seems to satisfy this

• How would the blacklist work when an operator could update their dig node to appear as a completely different node?

• How does an operator confirm the contents of a store before mirroring it? As noted in the docs there is the potential for illegal content to be stored and it is the node operator who would likely be liable. Is it possible for a node operator to be 100% certain that the store they are about to mirror does not contain illegal content? (this is not currently possible for other onchain data so I imagine it is not in this case as at the very least one would need to themselves review the content which in its own could be an illegal act)

[MichaelTaylor3D]

Why do node mirrors have to stake but sponsors do not?? It seems like sponsors should be required to stake x epochs worth of funds so that operators will always be paid rather than relying on trust of the sponsors. Just made it to the escrow vaults part that seems to satisfy this

The current documentation focuses on the alpha release, where I will primarily be covering the pay-to-propagate fees for testing purposes.

The goal for the 1.0 launch is to address this by introducing an "Escrow Coin." This coin will allow sponsors to prepay with a non-refundable deposit for mirror services. The Escrow Coin would function as a "secure the bag" mechanism, where the spend path requires an announcement from a DataLayer oracle before the DIG node is permitted to claim the funds.

The store sponsor must still be "trusted" to maintain the oracle. However, the non-refundable nature of the deposit ensures that if the sponsor fails to maintain the oracle, the money is lost. This encourages them to uphold their responsibilities to receive value from their deposit.

The main challenge in implementing this right now is a lack of funds to pay for further Chia Lisp development. Additionally, it requires "slots," which @Yakuhito is still working on. As a result, this will need to be a feature introduced later.

---

in the mean time, When a store sponsor pays out, they provide a hint to the payment that dig nodes can use to audit payment activity. There would need to be additional development to make a tool to streamline this, but they could in theory detect bad store sponsors and choose to blacklist them.

        const { epoch: currentEpoch, round: currentRound } = ServerCoin.getCurrentEpoch();
        const paymentHint = DigPeer.createPaymentHint(Buffer.from(program.storeId, "hex"));
        const message = Buffer.from(`Incentive program payout for storeId: ${program.storeId}, epoch ${currentEpoch}, round ${currentRound}`, "utf-8");
        const memo = [paymentHint, message];

Additionally, I'm looking into having DIG Nodes be able to filter Incentive Programs by their synthetic key. So you could whitelist store sponsors that you trust to automatically subscribe to stores for.

Example: I may put up a "Incentive Processing Service" that will automate payouts on behalf of data publishers and they would just have to keep the service topped off with XCH. Incentive programs from this service would be highly trusted compared to some random anynomous incentive program announced on chain.

---

In conclusion, i agree with you and am still articulating a solution for the store sponsors with the goal of creating a payment system that is provably fair. This is one of the last big challenges im facing where this system would be superior to any other project imo.

---

Verification process, when does the verification occur?? (having this occur too often would effectively be DoSing the operators but too little and uptime is not really monitored)

The verification is happening every 10 mins, and the challenges are actually pretty cheap to perform. If you think this is still to often it can be adjusted.

---

How can a node operator ensure the content of a store is safe before deciding to mirror it? The documentation mentions the risk of illegal content being stored, and the operator may be held liable for serving such content. Is there any way for an operator to be 100% sure that the store they plan to mirror is free of illegal material? Since other on-chain data systems can't guarantee this without personally reviewing the content (which could be illegal in itself), is this situation different?

I plan to discuss this issue further with legal experts as we go beyond the alpha launch, but here are my initial thoughts and strategies:

1. Content Indexing: According to Preston, it’s generally not illegal to index content. Liability typically arises when serving the content. Additionally the content isnt stored in a immediately readable form in the DIG Node so there is a level of plausible deniability. There may be schemes to break up a store across multiple nodes so no one node holds the full file. Not sure if i want to go down that route yet. But these are things that im constantly thinking about.

2. Content Protection: I’ll be updating the documentation to include guidance on using Cloudflare to wrap the DIG Node’s content server. Cloudflare provides CSAM detection, blocking, and reporting services for user-generated content. This would serve as the first layer of defense against serving illegal content.

3. Reporting and Blacklisting: We will establish a reporting form at csam.dig.net for community members to report suspicious stores. This form will create a blacklist that DIG Nodes will automatically subscribe to by default, helping prevent mirroring of flagged content.

4. Control Over Mirroring: Ultimately, DIG Node operators have full control over which stores they choose to mirror. They will likely prefer to mirror trusted sources to minimize risk.

5. Incentive Processing Service: As previously mentioned, I could run an "Incentive Processing Service" that could be whitelisted as "trusted" for DIG Nodes in mercenary mode. This service would constantly scan the stores it tracks and stop incentivizing any that contain illegal content. It would also report illegal material to authorities and add the store to the blacklist. DIG Nodes would then unsubscribe and delete the store.

These are just initial steps, and I’m hopeful we’ll come up with more ideas, tools, and solutions to protect DIG Node operators as the community around this technology grows and more people contribute their insights.

Additionally, I believe AI will soon offer solutions for better content scanning which i hope to incorporate.

---

How would the blacklist work when an operator could update their dig node to appear as a completely different node?

The black list is based in StoreId. DataStore Generations are immutable. Once content gets into a store and its flagged, its flagged forever. Yes someone could just create a new datalayer store. This will be one of the challenges we have to build solutions to.

We are not going to be able to prevent people from using the system in an undesirable way but we should be able to give DIG Node operators the tools to be in complete control over what they propagate.

---

Uptime and latency, aside from the verification process does this system have a means to verify uptime and latency? (if not then sponsors would be paying for poor data management/retention which is not ideal)

The reason I chose 10 mins intervals is because your paying for that 10 min round. So if they passed verification for that round, but they arnt up the entire round but are paid anyway its not a big loss.

We want to incentive high availability. So If a mirror fails a round, the store sponsor actually blacklists that ip address for the remainder of the epoch. The DIG Node gets a fresh chance in the next epochs, but they loose out on the rest of the current ones. This in theory should incentivize high available peers, while dropping unreliable peers.

Also still an area of active research and the mechanism will continue to get more robust as this evolves.

I am also interest in discussing other ideas. It was my hope that once i got people using this and interested, we could have some "roundtables" to help solve these last problems.

[BrandtH22]

Thank you for all of the answers! Looking forward to seeing where the project goes from here!