The same proof: I compared it using two routes. One runs locally on my computer, and the other is submitted to a third-party for delegated computation. The scenario is on a testnet, and the only variables left are the proof itself and the execution location. No need to exaggerate—the conclusion is already very clear: proofs require compute power, and compute power means someone has to pay the cost. “Cheapness” is a shift in ownership, not a cost that disappears out of thin air. These two records only compare which side the burden shows up on.
Piecrust’s host function lets the program initiate the corresponding computation, and the whitepaper also outlines the path for delegating computation to a third party. With local computation, the time spent and the device burden fall on the user. With delegated computation, the user carries less of the machine’s workload, but takes on a new relationship involving the service provider and the delegated computation fee. Third-party equipment also needs maintenance; you can’t ignore energy use and manpower on the service side. The logic is simple: neither of the two paths actually removes the cost.
After I submitted the same proof via both routes, the first thing I looked at was the waiting stage. The privacy experience of @Dusk can make the operations feel smoother, but “smoother” doesn’t mean “no cost.” Whether the button stays local or goes remote, there is still a waiting period before completion. When I submit via the delegated route and wait for results, I’m a bit uneasy—because during that time, the compute power is running on someone else’s machines, and the cost responsibility shifts accordingly to the other side.
Then I laid out the comparison table: the local column lists device and time costs, while the delegated column lists service and delegated computation fees. The value of $DUSK is to offer choices, not to pretend there’s only one no-cost answer. Factually speaking, delegated computation may be friendlier to users with lighter devices, but it introduces new variables: service dependency, fee definitions, and availability. If the delegated computation fee is charged per time, per amount, or by service packages, the prices will also create different usage thresholds. The boundary of compute cost is written into the comparison table.
So when you look at a privacy proof, don’t only ask whether it can be fast once. You also need to ask: who is doing the computation, who is waiting, and who is paying? For occasional users, saving on equipment doesn’t necessarily save the total price. Cost shifting can be a good design, but it doesn’t mean the cost disappears. Before choosing a route next time, write down a line for local compute power costs and a line for delegated computation fees, then decide which bill you’ll personally carry.#dusk
Piecrust’s host function lets the program initiate the corresponding computation, and the whitepaper also outlines the path for delegating computation to a third party. With local computation, the time spent and the device burden fall on the user. With delegated computation, the user carries less of the machine’s workload, but takes on a new relationship involving the service provider and the delegated computation fee. Third-party equipment also needs maintenance; you can’t ignore energy use and manpower on the service side. The logic is simple: neither of the two paths actually removes the cost.
After I submitted the same proof via both routes, the first thing I looked at was the waiting stage. The privacy experience of @Dusk can make the operations feel smoother, but “smoother” doesn’t mean “no cost.” Whether the button stays local or goes remote, there is still a waiting period before completion. When I submit via the delegated route and wait for results, I’m a bit uneasy—because during that time, the compute power is running on someone else’s machines, and the cost responsibility shifts accordingly to the other side.
Then I laid out the comparison table: the local column lists device and time costs, while the delegated column lists service and delegated computation fees. The value of $DUSK is to offer choices, not to pretend there’s only one no-cost answer. Factually speaking, delegated computation may be friendlier to users with lighter devices, but it introduces new variables: service dependency, fee definitions, and availability. If the delegated computation fee is charged per time, per amount, or by service packages, the prices will also create different usage thresholds. The boundary of compute cost is written into the comparison table.
So when you look at a privacy proof, don’t only ask whether it can be fast once. You also need to ask: who is doing the computation, who is waiting, and who is paying? For occasional users, saving on equipment doesn’t necessarily save the total price. Cost shifting can be a good design, but it doesn’t mean the cost disappears. Before choosing a route next time, write down a line for local compute power costs and a line for delegated computation fees, then decide which bill you’ll personally carry.#dusk