kobigurk: kobigurk: I actually already use the Web Crypto API to get a good random seed, but the pseudo random number generator in Rust, XorShiftRNG is not suitable for cryptographic applications. This can be improved, and I’m not sure which is the way to go - making an interface-compatible PRNG that calls the Web Crypto API or just a better PRNG in Rust.

Again, sorry if this is redundant, but I think randomness is really neat and would like to learn more! Looking through the Rust Rand Book it looks like they have options beyond XorShifting, but recommend ring , openssl , or Rust Crypto for more security/hardness. Are you looking for a harder version of the same XORShiftRNG or just a harder generator for random value?

kobigurk: kobigurk: I’ll try to answer assuming I understood correctly. If you have data that you can publicly verify came from an authentic source (i.e., it’s public, signed or hashed and published), you can indeed process it in the browser and provide only the result with a proof that the result was computed correctly. The crucial part is showing the data integrity - as the script can only run “locally” (it cannot call external systems), it has to provide some “anchor to reality” - i.e., the hash of the dataset the data is taken from. If I’m on the direction of your question, let me know

That’s very helpful. Thank you

I’m currently exploring protocols to get data from centralized web2 platforms/databases to decentralized blockchain platforms/databases. This requires verifying the source of the data as well as verifying that the script used to pull/scrape the data was executed correctly. Once the data has been verified, it’s added to the state of the blockchain and then anyone can build contracts or applications on-top that work with that data. That’s the idea anyways.

ATM I’m thinking to have a publicly released script that people can use to scrape a website and submit that data to the blockchain. Then there needs to be a way to verify that this script is run as intended and not a modified version. When you say that “it cannot call external systems”,

is this because the input/result of the external system cannot be verified and thus it breaks the whole thing?

or could you at least verify that the publicly released scraping script was compiled and run correctly, even if you can’t verify the data it will return? For example the script was not modified, it was run, and then this is the data it returned? This could maybe even be integrated into the script where the website to crawl (or API to connect to) is hard coded in, and the values it returns are stored in a HashMap of the script, and the script returns the HashMap. It can’t verify what’s in the HashMap, but it can verify that the script ran, got some values from the website it called, and those values are in the HashMap it’s returning. Is that possible?

Another approach I’m exploring is pulling the SSL cert of the website along with the other data the script pulls in order to verify the source of data. Or maybe using the TLS handshake to verify the connection. While those might help, ultimately we need to verify that the script was run correctly in the first place.

Also another usecase might be linking usernames on websites to wallets on the blockchain in an anonymous or pseudo anonymous way. For example:

a program is created that mints tokens for users based on Reddit karma/upvotes. Then, anyone who wants to access those tokens creates a wallet, posts a random string to Reddit, and then also sends that same random string to an account contract on the blockchain. The next time the scraping/API script runs the account verification contract checks the data to see if the random string is found in the data, and if so, the wallet is tied to that username and receives tokens accordingly.

edit: this could actually be augmented by posting a 1-time use public key to Reddit that anyone can verify, but then sending the corresponding private key to the verification contract (because only the person who created the public key would have the private key)

A few problems with this such as timing attacks, but mainly, that it forces a public link of identity.

Thinking that with a login system that uses zkSNARKs, you could prove that you know the pre-image of a key without having to reveal what that key is. This could help move towards pseudo anonymous verification of off-chain identities for on-chain systems. Of course someone could still do a network analysis and correlate which on-chain accounts receive tokens that match the karma of Reddit users, but it’s a little better than just a direct public link.

Anyways, these seemed related to usecases for ZK Proofs on the web so thought I’d share, but I’m more of a crypto enthusiast than anything so I apologize if some of this is obviously incorrect, redundant, or tangential at best lol