TON-EVM Bridge

`config_param` contains `bridge_address` and `oracles_address`. Governance (`multisig-code`) is saved as `oracles_address`. It can only send messages to `bridge_address` or to any address if it is no longer assigned as `oracles_address`. Bridge (`bridge_code`) is saved as `bridge_address`. It accepts "swap" commands from any address (locking TONs) or control commands from `oracles_address`. If Validators update both `config_param` values at once, then old Bridge no longer can get control commands: old Governance will be unauthorized, new Governance will send commands only to new Bridge. The reward accumulated on old Bridge will be locked. If Validators update only `bridge_address`, then old Bridge no longer can get control commands: Governance will send commands only to the new Bridge. That means that to perform a Bridge "migration", new Governance contract has to be modified to allow additional messages recipient, new Bridge contract has to be modified to accept `0xf00d` message. That can potentially lead to stake extraction risk.

`votes-collector` collects Secp256k1 signatures to be used in ETH Bridge call. One malicious oracle can submit invalid signatures to each voting. This will practically block the ETH side of the bridge - it will `revert()` trying to validate the signature. To restore the correct work, the honest oracles have to 1. Notice that ETH transactions are failing 2. Determine which signature is invalid 3. Cut the invalid signature from the list 4. Resubmit the failed ETH transactions 5. Ignore the malicious oracle in future This will likely take a significant time to implement.

`spend_delay` in fact holds the timestamp, not "delay".

The meaning of `state_flags` is not described. Setting the first bit prevents locking of TONs, however, doesn't prevent withdrawing.

Contract storage organization and incoming message layout are not described explicitly.

License Identifier should be on the first line.

```cpp=83 ;; int_msg_info$0 ihr_disabled:Bool bounce:Bool bounced:Bool src:MsgAddress -> 011000 var msg = begin_cell() .store_uint(0x10, 6) ;; #int_msg_info$0 ihr_disabled:Bool bounce:Bool bounced:Bool src:MsgAddressInt = 0 1 0 0 0 00 ``` First comment mentions the binary 011000 (0x18), however, the code uses 010000 (0x10). The second comment mostly duplicates the first one, but erroneously contains `MsgAddressInt` and wrong bit sequence.

There are typos: - "transder" is supposed to be "transfer" - "transfer" is supposed to be "burn"