btw, the day wasn't wasted, we discovered another bottleneck that required special attention, so we decided to deduce it from a proof-of-concept form, rather than simply as an algorithm and separately decided to prove that after any write, the state remains synchronized among all participants, a quorum requires both thresholds (number and weight of participants) to be met
the learning context itself, based on moving consensus, doesn't change the vote, lock, or finalization phase. this was a rather specific problem, so we decided to formalize it (sorry for the format - the OPD platform will be available in a couple of days, but for now, we're writing the descriptive part manually), so you can take a look at it here: gitlab.octra.org.uk/octra/li…
the new release marker is now available for validators, pls upgrade as usual:
sh controls/upgrade.sh
sh controls/upgrade.sh --apply
sh controls/stat.sh – at London, England
in the new version of the scan, formal verification, byte and src code, as well as program certs, have become more informative (this is still early alpha, it will change 1000%, but it has become more convenient to work with imo)
example: devnet.octrascan.io/program.… – at London, England
all matrices are multiplied by validators in devnet in the circle, @chiefofautism computed – at London, England
the test app, which we plan to release first on sepolia evm + octra devnet, and then add other networks, will allow sending ERC20 assets and gas coins between participants without disclosing the amount, sender, and recipient, outside the octra network (while octra is used as a computing layer for encrypted data)
it will be available completely open source, the application can be run locally (using the same principle as webcli), no trust environment, sharing keys, etc. – at London, England
