@mathewmeconry before going for the solution with oracles, we first had two prototypes with homomorphic encryption (similar to Solana) and ZKPs.
The ZKP prototype was about implementing equality proof in zokrates for the splitting a basket into two and joining two baskets into one. However, the proof generation was too intensive and the proof verification alone was 1M+ gas. Moreover, it was very costly to join or split multiple baskets at once. I am not sure, eventually now (~3y later) there are more efficient ZKP solutions to solve the challenge, we didn’t further investigate.
The other prototype (~5y ago) was with homomorphic encryption similar like Solana is solving it, however it was too expensive gas-wise as you already mentioned and it involved managing additional public/private key pairs for encryption/decryption. Moreover, we also got stuck in our prototype with solving the range and equality proofs, which Solana seems to have solved elegantly now!
Hence, we decided to go for the solution with oracles. For us it works well, because with banks we’re in a regulated environment where a security token will have a registrar (aka token operator). Like for instance required in German law for electronic securities (aka crypto securities). The registrar is the natural place to place the primary source for the off-chain data and also the oracle function. Moreover, in SWIAT we also have decentralized off-chain data management, which will automatically sync the confidential data between the nodes if the participant is eligible to read it. All these factors together make it a good and much simpler choice for the regulated environment in which we operate.
In regard to Solana’s solution: I like the approach very much, I also agree that Ethereum might also profit from the same confidentiality mechanism.