The onchain program should be shifted to solana instead of ethereum

[Nitish-bot]

I wanted to apply as a GSOC participant for the dApp idea and going over the requirements, I immediately thought solana would be a better choice for this and since the progress in the Ethereum direction is minimal, I would like to discuss the possibility of porting the current ethereum smart contract to solana.

There are quite a few reasons I believe solana would be a better choice for such a dApp:

• Greatly reduced gas fees
• No L2 delegation needed
• Supports privacy through projects like Arcium and MagicBlock

[pradeeban]

Good arguments, @Nitish-bot.

@Chali-healthy

[Chali-healthy]

Thanks @Nitish-bot. We would be curious to see your thoughts on a Solana deployment in your submission proposal. Look forward to reading it. Thank you @pradeeban

[santhil-cyber]

Interesting discussion and point @Nitish-bot and so fair point that its still early... the contract is on Sepolia testnet and the Solidity code isnt that big. so yes, a full rewrite is like technically possible right now.

but i dont think its really worth it tho. the migration cost isnt just rewriting DocumentStorage.sol in Rust/Anchor we also gotta replace the whole EVM integration layer: contractService.ts (ethers.js v6), MetaMask wallet stuff across many components, the Hardhat test suite, and all the Solidity stuff every contributor already knows. thats alot.

the main good thing about Solana is cheap gas fees. but we can get that same thing by just deploying the same contracts (no changes!!) to an L2 like Polygon or Arbitrum — transactions cost less than a cent, no contract rewrites, no wallet migration, no new testing framework. literally the only change is the RPC endpoint. thats it!!

on the privacy thing — Arcium and MagicBlock are cool and all, but Bio-Block already does PHI redaction at the app layer (Presidio, spaCy, OCR) before data even touches the chain. the blockchain only stores IPFS content hashes, never the actual patient data. so on-chain privacy stuff wouldnt really help here anyway.

so like... the real question is: is it worth rewriting the whole blockchain layer + frontend integration + test suite + wallet flow just to get cheap gas fees... when an L2 migration does the same thing with almost zero code changes?? i think we should just keep the Ethereum stack and move to an L2 when the platform is ready for production.

[pradeeban]

@santhil-cyber good points to consider. Also, especially in the context of the GSoC, this migration maybe orthogonal to the two Bio-Block GSoC projects, depending on how you approach it in your proposal (and consequently in your GSoC).

[adityajha2005]

From going through the codebase, it looks like the system already keeps sensitive data off-chain and uses the chain mainly for access control and auditability.
Given that, switching chains just for lower fees feels a bit overkill right now, since the same thing can be achieved by moving to an L2 without touching most of the existing contracts, integrations, or tooling.

For GSoC scope especially, it probably makes more sense to focus on building out the application layer (analytics, APIs, usability) instead of reworking the entire blockchain stack.

so keeping it modular now probably saves a lot of pain later if things change