The RC version is finally joining SORA.
The remaining three types of keys to be added to SORA L1 and the quantum-resistant multisig are expected to be released starting from the RC version.
Currently, the latest version (stable version) of SORA L1 is equipped with a “locality key” generated by [getkeyentangle] as the first key. By matching keys with Ethereum through [importprivethkey], it recognizes the same address as Ethereum, and from there, a dedicated address for entangling with SORA is obtained through [getkeyentangle].
Notably, this dedicated address for entangling is different from the address linked to the account (it’s not simply linked by account name). Therefore, the address obtained through [getaccountaddress] by passing the account name and the address obtained through [getkeyentangle] can be confirmed to be different.
When SORA is sent to the address obtained through [getkeyentangle], SORA arrives at the Ethereum-style address. This is the mechanism of the “locality key”.
Next, the “non-locality key,” which will be the second key to be mounted in the RC version, does not require [getkeyentangle], eliminating the need for it and incorporating the hidden address into the Ethereum-style address.
Since it’s non-locality, it necessitates the propagation of information to the SORA network. At this time, a certain amount of SORA’s permanent lock is required for one non-locality key because issuing non-locality keys indiscriminately could significantly burden the entire network.
Therefore, a cost is demanded. In return, this mechanism operates in such a way that the hidden address gets incorporated into the Ethereum-style address.
