@chirping_b3425 I am not opposed to expanding work load to other devoted devs if I come across them, I am slowly delegating non code based parts to associates who are helping keep everything running smoothly. Ideally as Zeno grows from v0 to more fortified versions our dev team has expanded.
I know progress may be slower than some have hoped but here's a little perspective.
I am a solo developer with a day job working on this as a passion project.
My goal is to have a v0 version of Zeno built within the next few weeks. In comparison Zcash was built by a team of devs over the course of 10 years.
Good projects take time and nurturing to be healthy and sustainable but progress is continuous so do not worry.
I am proud to have such a supporting community and proud to be a Zenite.
@guy49553 I can't give an exact date as progression is on going on I am building this as a passion project alone, but I am working diligently to bring a MVP to market. Ideally once our dev net works fully on our VPS I can migrate a final testnet to Hetzner Bare Metal server.
GM Zenites,
Our spend circuit is looking good. Our signal outputs for our root nullifier and commitment are all writing properly. Shielded transactions are slowly taking shape.
@jaml82984786 Being that all development is being done by myself alone, it is taking some time. Keep in mind I am trying to build Zeno within 3 months, Zcash took over 10 years.
Gm Zenites. Our lead dev has been sick the past couple days hence why we didn’t get to live stream this weekend.
We just wanted to get on here and let you know what was going on.
In other news, we do have some exciting updates for you this week so stay tuned.
$ZNO
We are still here and still working diligently. I checked on our VPS server earlier today and noticed a random tick up to 100% CPU usage, We are currently investigating the cause. We might be due for another server upgrade.
The more we build the more we need to expand the base server to allow for head room of the validator node.
In the future we might split the node from all other components of the Zeno website to allow the node to run without competing for server space with any of our other assets.
I noticed that on a VSP refresh out validator was not coming back online so instead of running it with pm2 its being configured to run via systemd.
This is basically how programs auto start on your computer when you restart your device.
Our proof generation relay is wired up and connected to our vps.
Next step is integrating the groth16 proving structure to verify proofs from our relay when transactions are submitted.
Thought this was funny and wanted to share. It's like they knew...
I am still working on the relayer this evening and will be doing another stream for you guys this weekend.
Some quick updates,
I'm working on shipping v0 version of Zeno, and to increase building efficiency we are going to restructure the community involvement aspect of the build process.
Instead of daily live streams, which impact the speed at which I am able to build, we will do weekly (or more) progress recaps on spaces and I will still be tweeting frequent updates on code progression.
Last nights stream involved building a new circuit for our proof compiler to allow interaction with our Merkle root. Currently I am working on building our relayer which will generate our proofs of chain and subsequently have them proved on chain.
As we ship more updates for Zeno we will build precompiles to utilize a BN254 curve natively as a syscall.
Gm Zenites, Thank you for tuning in last night, great vibes on stream with you all!
Got a few things to take care of today, both IRL and on the backend. Will post more updates later this afternoon.
We received a few good questions regarding the zkp integration:
Shielded transactions directly touch specified program accounts. Our shielded pool (or pools) will retain the most updated Merkle root. We will verify which proofs have been spent using a nullifier within the proof so transactions should perform as normal without being spent twice.
Natively Solana does not have integration for Ethereum based BN254 precompiles, to solve this proofs will need to be generated by a relayer or locally if we use a native wallet. On chain our verifier will utilize groth16 to check the verify the proof.
Our shielded system would require a shared global state meaning we cant run transactions in parallel since they will be touching the same accounts so they will be serialized (normal Solana behavior). This will slow down transactions speeds but this can be mitigated by creating multiple pools.
We are not attempting to hide the accounts touched, we are only hiding internal details of the transaction. These are proven inside the zk-SNARK and verified but don't impact the accounts touched.