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
main net, the home stretch
tomorrow evening, we'll begin onboarding validators* to the mainnet (those who have already set up nodes on the devnet won't have any difficulties, but for those just trying it out i recommend starting to learn about node setup and joining the validator group for coordination in telegram, if you're not already there)
what we have in the next 24 hours: two release markers for the devnet, a major webcli update, and a few other things if we can get it done tmw, but the main focus is the mainnet upgrade and onboarding (observing the achievements of our colleagues, it's time for us to participate)
* stock up on some oct coins to activate the bond on the mainnet
tg: t.me/octra_validators
lite node src: github.com/octra-labs/lite_n… – at London, England
the repo i mentioned earlier (few months ago), maintained by @androolloyd quite interesting, the README deserves special attention, he is developing an advanced decentralized vpn on circles
github.com/androolloyd/octra… – at London, England
pure HFHE absorber funcs and homomorphic addition on a live devent (unconditionally confirmed by all validators), a live example of a primitive:
the program containing the primitive is located here - oct37eKZvSCfYfcqKrQxfTmnE4fcsZReZ4iVWPsS9KqHnAj
tx 1 - 321664a358c4d9df6132708d0d41f6d72550414406b299cfed5e74059b01b8d9 (epoch 1452937, effort 5959),
tx 2 - 018d7c2f1bfebef45824971ad80cb3d69c0e9a306afc59ccda878644248e09f1 (epoch 1452939, effort 11974). input ciphertexts are 3 and 4 (two primes), 42 and 43 kilobytes, the amount is encrypted in the state, weight 85 Kb.
a fun fact: the second call is twice as expensive because FHE_ADD was executed for the first time, meanwhile, the opcodes FHE_LOAD_PK, FHE_DESER, FHE_ADD, and FHE_SER passed through the VM of all validators, and none of them saw the values.
this example will be part of the basis for a private tx and exec proto (with anonymity) between EVM and octra (first octra devnet + ETH Sepolia, and then mainnet) – at London, England
