Core Development: Ephemeral Accounts

This is a formal proposal for finalizing the ephemeral accounts (EAs) implementation. Although work has already been done to implement EA’s, it is my understanding that work has not yet completed to achieve full implementation.

EA’s have many uses cases and makes sharing data significantly faster and easier. Specifically, sharing data that does not have to be routed through any outside infrastructure. Currently the only way to avoid a bandwidth bottleneck associated with data routing is to create a new contract-set that is sent to the customer. Unfortunately contract creation is expensive and has scalability limitations. StoreWise for example will use ephemeral accounts for read-only buckets where users receive EA’s instead of Sia contracts. Security wise the upside of sending users EA’s instead of contracts is that EA’s prevent the contracts holding the data from being tampered with by unauthorized users.

Additionally i would like to request that EA’s are not only merged into siad but into us as well.

The EA system is pretty involved, I think it took PJ nearly 3 months to get set up with significant ongoing help from myself and Chris. Is there some way that we can reuse the code, or maybe add some endpoints to give you lower level control over EAs from siad?

Most of the complexity comes from the adversarial cases - what happens if the host defects or steals money? What happens if a bad actor tries to re-use signatures or spend EAs multiple times, etc. And then the rest of the complexity comes from managing error cases. What happens if the host goes offline randomly in the middle, what about the renter, etc?

Should this proposal be extended to a low level RHP3 implementation over specifically EA’s? Sia Central’s RHP3 benchmarks use the MDM and EA payments outside of siad, a lower level implementation or an official spec would have saved a ton of hours. IIRC, Filebase was also interested in an officially supported us-like library.

IIRC, Filebase was also interested in an officially supported us -like library.

I merged an us package late last year that implements the underlying “SiaMux” transport protocol. I’ve held off on pursuing a low-level RHP3 library because the protocol is still evolving, but that seems like the sort of library that the Foundation would support.