profile
viewpoint
Illia Polosukhin ilblackdragon NEAR Protocol San Francisco, CA

google-research-datasets/wiki-reading 249

This repository contains the three WikiReading datasets as used and described in WikiReading: A Novel Large-scale Language Understanding Task over Wikipedia, Hewlett, et al, ACL 2016 (the English WikiReading dataset) and Byte-level Machine Reading across Morphologically Varied Languages, Kenter et al, AAAI-18 (the Turkish and Russian datasets).

ilblackdragon/django-themes 45

Application for django framework, provides flexible and configurable theming system.

ilblackdragon/adversarial_workshop 39

Adversarial Workshop code and presentation

ilblackdragon/django-blogs 36

Blog app for django. Provide blogging functionality for you django project. Multiblogging system, blog per user blog, one user blog are available for you in one app.

ilblackdragon/django-misc 16

Django-misc - module with different useful stuff for django. Here you'll find: couple decorators, like render_to and receive; json_encode module for simplify work with json, some usefull templatetags, like set, filter, get etc; some additional utilities; bbcode template tags; template tags that provide like and share for social sevices

ilblackdragon/GAN 5

GAN experiments

ilblackdragon/aiprog 4

AI programs

ilblackdragon/data-science-starter-kit 4

Data Science Starter Kit repository to organize your Data Science projects (Python-based mostly at this point of time)

ilblackdragon/django-localeurl 4

A Django application that allow you to specify the language of a page in the URL. Fork from https://bitbucket.org/carljm/django-localeurl

ilblackdragon/django-manager 4

Template for django project using our conventions

PullRequestReviewEvent

issue openednear/near-explorer

Some incoming function calls are not shown

For example, there are definitely more incoming function calls to this account - https://explorer.near.org/accounts/transfer-vote.near but they are not shown in the history.

created time in 7 hours

issue openednearprotocol/nearcore

Update default bootnodes for mainnet

The nodes that are in the config are offline. We should switch to using RPC nodes as boot nodes and may be sample of some well establish other validator nodes.

created time in 7 hours

issue openednear/near-explorer

Implicit accounts don't have any data about creation

For example https://explorer.testnet.near.org/accounts/1b3107c66e0ad2f3e4054c2f9d81d9d60f4254b86adc204fa5dac345a193f264

Doesn't have created date.

Implicit accounts are created via transfer of money to the account that didn't exist before with length of ID 64 and being a hex of the public key.

created time in 8 hours

PR opened near/near-cli

Reviewers
Fix issue in seed phrase middleware

Propagate correctly networkId into key store

+2 -2

0 comment

1 changed file

pr created time in 10 hours

create barnchnear/near-cli

branch : fix-seed-phrase-middleware

created branch time in 10 hours

pull request commentnear/near-explorer

have vote function

@frol https://near.org/blog/mainnet-phase-i/

there is no anchor but "The vote to launch Phase II"

also https://near.org/blog/mainnet-roadmap/

icerove

comment created time in 11 hours

push eventnear/rainbow-bridge-lib

Illia Polosukhin

commit sha b7f0427e02d288378ece8d9ebc27cf2ff0c4bdfd

Support BorshContract to still serialize/deserialize with JSON and await on readiness

view details

push time in 4 days

push eventnearprotocol/nearcore

Illia Polosukhin

commit sha c2131d0e6630ebd3e0e744c89b03db006bdf1749

Fix approximation of meta transactions in EVM

view details

Illia Polosukhin

commit sha 77edc0b08b19745b0b7d74a55f9e5433ef795f84

Updated meta tx to include domain / types. Updating to use evm/*.evm as accounts that have evm contracts

view details

push time in 4 days

PullRequestReviewEvent

Pull request review commentnearprotocol/nearcore

Evm gas estimation

 impl EvmState for SubState<'_> {     } } +pub struct EvmGasCounter {+    pub used_gas: U256,+    pub max_gas: U256,+}++impl EvmGasCounter {+    pub fn new(used_gas: U256, max_gas: U256) -> EvmGasCounter {+        Self { used_gas, max_gas }+    }++    pub fn pay_gas(&mut self, amount: U256) {+        // TODO: return error if gas not sufficient+        self.used_gas += amount;+    }++    pub fn set_gas_left(&mut self, left: U256) {+        self.used_gas = self.max_gas - left;

self.max_gas.saturated_sub(left)

ailisp

comment created time in 4 days

pull request commentnearprotocol/NEPs

Native EVM

Meta transaction message format

Requirements:

  • different chains (testnets, forks) should differ on the chainId. Need to add chain id to https://github.com/ethereum-lists/chains
  • update to the version of the EVM internal protocol should invalidate the signature
  • keep track of the nonce of the signer to prevent replays
  • message differs for different EVMs

Data format complaint with EIP-712:

  • \x19\x01 - prefix for EIP-712
  • domainSeparator: keccak256(abi.encode( keccak256("EIP712Domain(string name,string version,uint256 chainId)"), keccak256(bytes("NEAR")), keccak256(bytes(1)), chainId, // how about 1313161554? hex of NEAR? ));
  • keccak256(abi.encode( keccak256("NearTx(string evmId, uint256 nonce, address contractAddress, bytes arguments)", bytes("<evmId>"), // NEAR account id of the EVM bytes(nonce), // nonce of the given account bytes(contractAddress) // address inside this EVM arguments ));
ilblackdragon

comment created time in 4 days

issue commentnear/bounties

Rainbow Bridge Ampleforth Connector | Bounty TBD

@defiboy assigned it to you here. Feel free to ping us with questions in https://near.chat, also can connect with AMPL team if there are questions.

ilblackdragon

comment created time in 5 days

issue openednear/bounties

Ampleforth Ethereum <> NEAR connector | Bounty TBD

NEAR Bounty Terms

This is part of https://near.org/rainbow hackathon.

Description

Implement Rainbow bridge connector for Ampleforth.

Context

AMPL is an adaptive base-money, that adjusts total supply based on supply and demand. Can learn more https://www.ampleforth.org/

Rainbow Bridge has a generic ERC-20 connector implementation. But AMPL token won't work correctly with it, because of rebase - function that changes denomination of the token every day.

This bounty is about cloning a single token connector and customizing it to keep track of rebases and also communicating rebases from Ethereum to NEAR.

Relevant repos or issues

  • Generic erc-20 tokens bridge connector: https://github.com/near/rainbow-token-connector
  • A single token bridge connector:
    • Rust: https://github.com/near/rainbow-bridge-rs/tree/master/mintable-fungible-token/
    • Ethereum side: https://github.com/near/rainbow-bridge-sol/tree/master/token-locker
  • Ampleforth contracts: https://github.com/ampleforth/uFragments

The way to correctly do accounting due to rebases:

When amount is deposited / withdrawn from ETH/NEAR is to use internal amount (e.g. divide by total supply). E.g. if Alice has 1,000 AMPL currently and total supply is 2,000, internally she has 100,000,000 (e.g. whatever the internal denomination is used). Which will be sent to the other chain and rehydrated back depending on current rebase. This is important, because if the event was created pre-rebase, but the token arrives on the other side after rebase happened - the external amount will be incorrect. Internal amount (e.g. pre rescaling with rebase) will allow that on arrival can recalculate based on the current multiplier.

For example Alice sent 50 AMPL to NEAR. Right after the rebase happened and adjusted 2x the total supply. E.g. this 50 AMPL became 100 AMPL. For example the contract on NEAR actually received rebase event before Alice called deposit on NEAR side. If 100,000,000 of internal denomination arrive, contract just multiplies back to 1/50,000 and receive 2000 AMPL on NEAR side.

Acceptance Criteria

  • [ ] Contract on Solidity/Ethereum side that can lock and unlock AMPL. When AMPL gets unlock, the amount should be correct given possible rebases that have happened
  • [ ] Contract on Rust/NEAR side that can mint/burn nAMPL. Additionally, it would receive rebase events from AMPL ERC-20 contract and adjust total supply as well.

Bounty

TBD

created time in 7 days

issue openednear/near-cli

Offline transaction signing support

Currently CLI requires online machine.

Next UX suggested:

near <any tx sending command> --offline --blockHash=<recent blockHash> --nonce=<nonce>

Where --offline will fail if there is not transaction created. blockHash and nonce is required to populate the tx information. Otherwise will prints near broadcast-tx "<base64 of the transaction>" to use for broadcasting on an online machine.

Additional command to broadcast existing transaction:

near broadcast-tx "<base64 of transaction>"

Implementation detail:

  • The simplest way is to add OfflineProvider that would override few of the used end points to return data from arguments and record transmitted transaction.
  • OfflineMiddleware rewrites connection at the start with this provider and at the end shows the transaction(s) that were recorded.

This may not work with all commands (like repl) so can have a whitelist of subcommands that work and show error for the rest.

created time in 7 days

pull request commentnearprotocol/NEPs

Native EVM

Relevant links to meta transaction discussions in Ethereum:

  • https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md (signTypedData)
  • https://github.com/ethereum/EIPs/issues/1776 (meta transaction proposal)
  • https://medium.com/bloxis/generalised-ethereum-meta-transactions-our-take-cb9f027866e9
  • https://github.com/makerdao/dss/blob/b1fdcfc9b2ab7961bf2ce7ab4008bfcec1c73a88/src/dai.sol#L114-L138
ilblackdragon

comment created time in 7 days

issue closednear/near-web3-provider

Bug: cargo error

Investigate further. Additional info in #44 comments.

[/home/james/.cargo/registry/src/github.com-1ecc6299db9ec823/wasmer-runtime-core-0.17.0/src/instance.rs:609] &error = User(
    Any,
)
Jul 30 13:14:48.519  INFO stats: #     574 BRtL8Q9Ht3HmApsBbfEnP9RUNBtTme3PWeLfvhE2fzhs V/1  0/0/40 peers ⬇ 0 B/s ⬆ 0 B/s 4.70 bps 9.91 Tgas/s CPU: 6%, Mem: 133.9 MiB    
[/home/james/.cargo/registry/src/github.com-1ecc6299db9ec823/wasmer-runtime-core-0.17.0/src/instance.rs:609] &error = User(
    Any,
)
Jul 30 13:14:58.521  IN

closed time in 7 days

barbaraliau

issue commentnear/near-web3-provider

Bug: cargo error

Outdated.

barbaraliau

comment created time in 7 days

issue closednear/near-web3-provider

Support necessary calls to run truffle tests

Looks like we are missing such calls typically involved in truffle tests execution:

  • evm_revert
  • evm_snapshot
  • eth_getLogs

Looks like revert/snapshot is most challenging to implement as we don't have this feature at nearcore level. I see at least such options however:

  • we can be creating ephemeral nearcore runtime for every test, like e.g. now we have mock context for AssemblyScript https://github.com/nearprotocol/wasm-mock-vm.
  • we can implement snapshot/revert inside of EVM contract. Not sure how hard it is within current implementation.

closed time in 7 days

vgrichina

issue commentnear/near-web3-provider

Support necessary calls to run truffle tests

Generally, truffle tests work now with precompiles outside of revert/snapshot functionality which is not supported by nearcore.

Will create a separate issue when those things will be needed.

vgrichina

comment created time in 7 days

pull request commentnearprotocol/NEPs

Native EVM

Open question: how to allow Ethereum meta transactions to propagate to WASM contracts.

WASM contracts will require account_ids: signer_id and predecessor_id. But we don't have ecdsa implicit accounts, which means that can not infer one from the key (CC @evgenykuzyakov). Also rewriting signer_id is dangerous, but can rewrite predecessor_id if we can infer an account somehow.

Use case:

  • Use signs a meta-tx with Metamask to call sometoken to transfer some funds out.
  • It gets relayed to evm contract meta_tx method.
  • This creates a promise to sometoken.transfer where predeccessor is some account of the user that signed transaction.
ilblackdragon

comment created time in 8 days

Pull request review commentnearprotocol/nearcore

WIP: EVM precompile

 use near_primitives::transaction::{ }; use near_primitives::types::{AccountId, EpochInfoProvider, ValidatorStake}; use near_primitives::utils::{-    is_valid_account_id, is_valid_sub_account_id, is_valid_top_level_account_id,+    is_valid_account_id, is_valid_sub_account_id, is_valid_top_level_account_id, EVM_CODE_HASH,+};+use near_primitives::version::{+    ProtocolVersion, CORRECT_RANDOM_VALUE_PROTOCOL_VERSION,+    IMPLICIT_ACCOUNT_CREATION_PROTOCOL_VERSION, };+use near_runtime_configs::AccountCreationConfig; use near_runtime_fees::RuntimeFeesConfig; use near_runtime_utils::is_account_id_64_len_hex; use near_store::{     get_access_key, get_code, remove_access_key, remove_account, set_access_key, set_code,     StorageError, TrieUpdate, };+use near_vm_errors::{CompilationError, FunctionCallError, InconsistentStateError}; use near_vm_logic::types::PromiseResult;-use near_vm_logic::VMContext;+use near_vm_logic::{VMContext, VMOutcome};+use near_vm_runner::VMError;  use crate::config::{safe_add_gas, RuntimeConfig}; use crate::ext::RuntimeExt; use crate::{ActionResult, ApplyState};-use near_crypto::PublicKey;-use near_primitives::errors::{ActionError, ActionErrorKind, ExternalError, RuntimeError};-use near_primitives::version::{-    ProtocolVersion, CORRECT_RANDOM_VALUE_PROTOCOL_VERSION,-    IMPLICIT_ACCOUNT_CREATION_PROTOCOL_VERSION,-};-use near_runtime_configs::AccountCreationConfig;-use near_vm_errors::{CompilationError, FunctionCallError};-use near_vm_runner::VMError; -pub(crate) fn get_code_with_cache(-    state_update: &TrieUpdate,-    account_id: &AccountId,-    account: &Account,-) -> Result<Option<Arc<ContractCode>>, StorageError> {-    debug!(target:"runtime", "Calling the contract at account {}", account_id);-    let code_hash = account.code_hash;-    let code = || get_code(state_update, account_id, Some(code_hash));-    crate::cache::get_code(code_hash, code)+/// Runs given function call with given context / apply state.+/// Precompiles:+///  - 0x1: EVM interpreter;+pub(crate) fn execute_function_call(+    apply_state: &ApplyState,+    runtime_ext: &mut RuntimeExt,+    account: &mut Account,+    predecessor_id: &AccountId,+    action_receipt: &ActionReceipt,+    promise_results: &[PromiseResult],+    function_call: &FunctionCallAction,+    action_hash: &CryptoHash,+    config: &RuntimeConfig,+    is_last_action: bool,+    is_view: bool,+) -> (Option<VMOutcome>, Option<VMError>) {+    if account.code_hash == *EVM_CODE_HASH {

*.evm is still true - just didn't change here yet. Need to figure out rule for *.evm accounts creation.

ilblackdragon

comment created time in 8 days

PullRequestReviewEvent

push eventnear/core-contracts

Illia Polosukhin

commit sha e8764c62134671e895789a8d1a9124c3d1d0b510

Few minor tweaks

view details

push time in 9 days

push eventnear/core-contracts

Illia Polosukhin

commit sha bec83ad607183f3cf412cb2668a89696b8a06609

Finish addressing integration tests

view details

push time in 9 days

issue openednear/near-sdk-rs

Improve testing / introduce Rust API

So currently we are wriitng method names in string and passing arguments in JSON. In integration tests this leads to a weird json parsing errors when things don't match.

We are also introducing more borsh arguments for method names. Which means soon we will end up with ABIs pretty much.

Suggestion to add a set of marcos and tools to infer the API for using contracts. This also will serve not just for testing but also as rust-api-rs, which we currently don't have.

#[derive_json_abi]
struct FungibleToken {
    pub fn new();
    pub fn transfer(&mut self);
    pub fn transferFrom(&mut self, …);
    pub fn balanceOf(&self, owner_id: AccountId) -> Balance;
}

OR #[derive_borsh_abi] OR

load_abi!(FungibleToken, 'path/to/abi');

and then

let mut contract = FungibleToken::???(runtime, contract_account_id); // this would just create a contract object for given 

OR

// This would deploy contract, call new and create a object.
let mut contract = FungibleToken::deploy(runtime, signer_id, code, /* args for new call */);

Can use then:

contract.transfer(signer_id, to_id, amount);
contract.balanceOf(owner_id);
etc

We can hide signer into contract when creating one, but it’s a bit confusing in JS IMO.

Given runtime has very similar API to our RPC, this APIs should take a trait in which StandaloneRuntime and RustRPCProvider can implement.

created time in 9 days

push eventnear/core-contracts

Illia Polosukhin

commit sha 94cca954da3ceb34724239d91fc6537fce5b9f2b

Make foundation account optional again

view details

push time in 9 days

issue commentnear/rainbow-bridge-cli

Implement Upgradability

On the NEAR side we can leverage next pattern (which is similar to Ethereum):

struct Upgradable {
   owner: AccountId
}
impl Upgradable {
  /// Updates code and calls migration method if not empty?
   pub fn upgrade(&mut self, code, migrate_method_name: &str, args: Vec<u8>) { assert_eq!(env::predeccesor_id(), self.owner); // promise to itself to call DeployContract }
   pub fn change_owner(&mut self, new_owner) ...
}

We can possibly split this into Ownable and Upgradable that requires Ownable.

This way we can deploy already with an account we control, and then change owner to an account that is voted by our validators.

It also decouples the voting from bridge itself, which is cleaner and allows us to test it separately even on MainNet to check that validators have the tools to vote.

nearmax

comment created time in 9 days

Pull request review commentnearprotocol/NEPs

Define client versioning through interfaces not protocol

 type ProtocolVersion = u32;  ## Client versioning -Clients should follow [semantic versioning](https://semver.org/).+Clients should follow [semantic versioning](https://semver.org/). Our client is available both as an executable and as a library. We keep their versions in sync since executable is just a command line parser over the library.+ Specifically:- - MAJOR version defines protocol releases.- - MINOR version defines changes that are client specific but require database migration, change of config or something similar. This includes client-specific features. Client should execute migrations on start, by detecting that information on disk is produced by previous version and auto-migrate it to new one.-  - PATCH version defines when bug fixes, which should not require migrations or protocol changes.+ - MAJOR version defines non-backward compatible API and behavior changes. Specifically, if any kind of old client input produces different output on the new client, whether it is used an executable or a library. Whether it is being used by another client implementation, a third-party service, like bridge, wallet, or by another Rust crate, e.g. for Explorer Indexer. Examples of executable client input: RPC requests (including contract calls), incoming network messages, disk storage. Examples of executable client output: RPC responses, outgoing network messages, modifications to disk storage. Examples of library client input: messages send to publicly accessible actors. Examples of library client output: messages received from publicly accessible actors. Non-intuitive examples of when MAJOR version update is needed:+   - Anything that requires database migration, even if client self-migrates its database;+   - Error format of the RPC, including compilation errors. Which implies that major updates to Wasm runtime can cause version bump, even if they do not change the protocol;+   - The way publicly accessible actors handle messages;+   - When client changes its behavior after X's block -- delayed non-backward compatible API and behavior change, which includes most of the protocol changes.+- MINOR version defines backward compatible API and behavior changes, this mostly applies to extensions Non-intuitive examples of when MINOR version upgrade is needed:+   - New RPC endpoints;+   - Additional optional storage columns, e.g. on-disk cache.

What is the point of patch then if minor version should be fully compatible for running? From what I read it says minor is any backward compatible change but doesn't mean that you can still run old binary - because if some feature was added it's possible you can't reverse anymore due to some changes even in installable software.

nearmax

comment created time in 9 days

PullRequestReviewEvent

issue commentnearprotocol/NEPs

Advanced Fungible Token Standard

We actually were trying to remove need of approve + transferFrom originally in NEP-21 via async calls and callbacks, but end up going back on that. @evgenykuzyakov have more context on the runtime implications of that.

Agree that with meta transaction type of thing, there is a lot more can be done.

We are also adding EVM with native meta-transaction support (e.g. msg.sender will be correct).

miohtama

comment created time in 9 days

Pull request review commentnearprotocol/nearcore

WIP: EVM precompile

+#[macro_use]+extern crate lazy_static_include;++use borsh::BorshSerialize;+use ethabi_contract::use_contract;+use ethereum_types::{Address, H256, U256};++use near_evm_runner::types::{TransferArgs, WithdrawArgs};+use near_evm_runner::utils::{+    address_from_arr, address_to_vec, encode_call_function_args, encode_view_call_function_args,+    near_account_id_to_evm_address, u256_to_arr,+};+use near_runtime_fees::RuntimeFeesConfig;+use near_vm_errors::{EvmError, VMLogicError};+use near_vm_logic::mocks::mock_external::MockedExternal;+use near_vm_logic::VMConfig;++use crate::utils::{accounts, create_context, setup};++mod utils;++use_contract!(soltest, "tests/build/SolTests.abi");+use_contract!(subcontract, "tests/build/SubContract.abi");+use_contract!(create2factory, "tests/build/Create2Factory.abi");+use_contract!(selfdestruct, "tests/build/SelfDestruct.abi");++lazy_static_include_str!(TEST, "tests/build/SolTests.bin");+lazy_static_include_str!(FACTORY_TEST, "tests/build/Create2Factory.bin");+lazy_static_include_str!(DESTRUCT_TEST, "tests/build/SelfDestruct.bin");+lazy_static_include_str!(CONSTRUCTOR_TEST, "tests/build/ConstructorRevert.bin");++#[test]+fn test_funds_transfers() {+    let (mut fake_external, vm_config, fees_config) = setup();+    let context = create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 0);+    assert_eq!(+        context.get_balance(address_to_vec(&near_account_id_to_evm_address(&accounts(1)))).unwrap(),+        U256::from(0)+    );+    let mut context =+        create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 100);+    assert_eq!(+        context.deposit(address_to_vec(&near_account_id_to_evm_address(&accounts(1)))).unwrap(),+        U256::from(100)+    );+    let mut context = create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 0);+    context+        .transfer(+            TransferArgs {+                address: near_account_id_to_evm_address(&accounts(2)).0,+                amount: u256_to_arr(&U256::from(50)),+            }+            .try_to_vec()+            .unwrap(),+        )+        .unwrap();+    assert_eq!(+        context.get_balance(address_to_vec(&near_account_id_to_evm_address(&accounts(2)))).unwrap(),+        U256::from(50)+    );+    let mut context = create_context(&mut fake_external, &vm_config, &fees_config, accounts(2), 0);+    context+        .withdraw(+            WithdrawArgs { account_id: accounts(2), amount: u256_to_arr(&U256::from(50)) }+                .try_to_vec()+                .unwrap(),+        )+        .unwrap();+    assert_eq!(+        context.get_balance(address_to_vec(&near_account_id_to_evm_address(&accounts(2)))).unwrap(),+        U256::from(0)+    );+}++#[test]+fn test_deploy_with_nonce() {+    let (mut fake_external, vm_config, fees_config) = setup();+    let mut context = create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 0);+    let address = near_account_id_to_evm_address(&accounts(1));+    assert_eq!(context.get_nonce(address.0.to_vec()).unwrap(), U256::from(0));+    let address1 = context.deploy_code(hex::decode(&TEST).unwrap()).unwrap();+    assert_eq!(context.get_nonce(address.0.to_vec()).unwrap(), U256::from(1));+    let address2 = context.deploy_code(hex::decode(&TEST).unwrap()).unwrap();+    assert_eq!(context.get_nonce(address.0.to_vec()).unwrap(), U256::from(2));+    assert_ne!(address1, address2);+}++#[test]+fn test_failed_deploy_returns_error() {+    let (mut fake_external, vm_config, fees_config) = setup();+    let mut context = create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 0);+    if let Err(VMLogicError::EvmError(EvmError::DeployFail(_))) =+        context.deploy_code(hex::decode(&CONSTRUCTOR_TEST).unwrap())+    {+    } else {+        panic!("Should fail");+    }+}++#[test]+fn test_internal_create() {+    let (mut fake_external, vm_config, fees_config) = setup();+    let mut context = create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 0);+    let test_addr = context.deploy_code(hex::decode(&TEST).unwrap()).unwrap();+    assert_eq!(context.get_nonce(test_addr.0.to_vec()).unwrap(), U256::from(0));++    // This should increment the nonce of the deploying contract+    let (input, _) = soltest::functions::deploy_new_guy::call(8);+    let raw = context.call_function(encode_call_function_args(test_addr, input)).unwrap();+    assert_eq!(context.get_nonce(test_addr.0.to_vec()).unwrap(), U256::from(1));++    let sub_addr = address_from_arr(&raw[12..32]);+    let (new_input, _) = subcontract::functions::a_number::call();+    let new_raw = context.call_function(encode_call_function_args(sub_addr, new_input)).unwrap();+    let output = subcontract::functions::a_number::decode_output(&new_raw).unwrap();+    assert_eq!(output, U256::from(8));+}++#[test]+fn test_precompiles() {+    let (mut fake_external, vm_config, fees_config) = setup();+    let mut context =+        create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 100);+    let test_addr = context.deploy_code(hex::decode(&TEST).unwrap()).unwrap();++    let mut context = create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 0);+    let (input, _) = soltest::functions::precompile_test::call();+    let raw = context.call_function(encode_call_function_args(test_addr, input)).unwrap();+    assert_eq!(raw.len(), 0);+}++fn setup_and_deploy_test() -> (MockedExternal, Address, VMConfig, RuntimeFeesConfig) {+    let (mut fake_external, vm_config, fees_config) = setup();+    let mut context =+        create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 100);+    let test_addr = context.deploy_code(hex::decode(&TEST).unwrap()).unwrap();+    assert_eq!(context.get_balance(test_addr.0.to_vec()).unwrap(), U256::from(100));+    (fake_external, test_addr, vm_config, fees_config)+}++#[test]+fn test_deploy_and_transfer() {+    let (mut fake_external, test_addr, vm_config, fees_config) = setup_and_deploy_test();++    // This should increment the nonce of the deploying contract.+    // There is 100 attached to this that should be passed through.+    let (input, _) = soltest::functions::deploy_new_guy::call(8);+    let mut context =+        create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 100);+    let raw = context.call_function(encode_call_function_args(test_addr, input)).unwrap();+    assert!(context.logs.len() > 0);++    // The sub_addr should have been transferred 100 yoctoN.+    let sub_addr = raw[12..32].to_vec();+    assert_eq!(context.get_balance(test_addr.0.to_vec()).unwrap(), U256::from(100));+    assert_eq!(context.get_balance(sub_addr).unwrap(), U256::from(100));+}++#[test]+fn test_deploy_with_value() {+    let (mut fake_external, test_addr, vm_config, fees_config) = setup_and_deploy_test();++    // This should increment the nonce of the deploying contract+    // There is 100 attached to this that should be passed through+    let (input, _) = soltest::functions::pay_new_guy::call(8);+    let mut context =+        create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 100);+    let raw = context.call_function(encode_call_function_args(test_addr, input)).unwrap();++    // The sub_addr should have been transferred 100 tokens.+    let sub_addr = raw[12..32].to_vec();+    assert_eq!(context.get_balance(test_addr.0.to_vec()).unwrap(), U256::from(100));+    assert_eq!(context.get_balance(sub_addr).unwrap(), U256::from(100));+}++#[test]+fn test_contract_to_eoa_transfer() {+    let (mut fake_external, test_addr, vm_config, fees_config) = setup_and_deploy_test();++    let (input, _) = soltest::functions::return_some_funds::call();+    let mut context =+        create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 100);+    let raw = context.call_function(encode_call_function_args(test_addr, input)).unwrap();++    let sender_addr = raw[12..32].to_vec();+    assert_eq!(context.get_balance(test_addr.0.to_vec()).unwrap(), U256::from(150));+    assert_eq!(context.get_balance(sender_addr).unwrap(), U256::from(50));+}++#[test]+fn test_get_code() {+    let (mut fake_external, test_addr, vm_config, fees_config) = setup_and_deploy_test();+    let context = create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 0);++    assert!(context.get_code(test_addr.0.to_vec()).unwrap().len() > 1500); // contract code should roughly be over length 1500+    assert_eq!(context.get_code(vec![0u8; 20]).unwrap().len(), 0);+}++#[test]+fn test_view_call() {+    let (mut fake_external, test_addr, vm_config, fees_config) = setup_and_deploy_test();++    // This should NOT increment the nonce of the deploying contract+    // And NO CODE should be deployed+    let (input, _) = soltest::functions::deploy_new_guy::call(8);+    let mut context = create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 0);+    let raw = context+        .view_call_function(encode_view_call_function_args(+            test_addr,+            test_addr,+            U256::from(0),+            input,+        ))+        .unwrap();+    assert_eq!(context.get_nonce(test_addr.0.to_vec()).unwrap(), U256::from(0));++    let sub_addr = raw[12..32].to_vec();+    assert_eq!(context.get_code(sub_addr).unwrap().len(), 0);+}++#[test]+fn test_solidity_accurate_storage_on_selfdestruct() {+    let (mut fake_external, vm_config, fees_config) = setup();+    let mut context =+        create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 100);+    assert_eq!(+        context.deposit(near_account_id_to_evm_address(&accounts(1)).0.to_vec()).unwrap(),+        U256::from(100)+    );++    // Deploy CREATE2 Factory+    let mut context = create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 0);+    let factory_addr = context.deploy_code(hex::decode(&FACTORY_TEST).unwrap()).unwrap();++    // Deploy + SelfDestruct in one transaction+    let salt = H256([0u8; 32]);+    let destruct_code = hex::decode(&DESTRUCT_TEST).unwrap();+    let input = create2factory::functions::test_double_deploy::call(salt, destruct_code.clone()).0;+    let raw = context.call_function(encode_call_function_args(factory_addr, input)).unwrap();+    assert!(create2factory::functions::test_double_deploy::decode_output(&raw).unwrap());+}

There is no way to provide nonce to evm.

ilblackdragon

comment created time in 9 days

PullRequestReviewEvent

issue commentnearprotocol/NEPs

Detailed spec of `Genesis::total_supply`

That's not what I meant per se - the field is well defined and it's clear why it increased if you observe the final genesis file. I meant that we should remove that field from the config on disk, because it is inferable from state records.

We kind of using this field as an assert to make sure that record balances are adding up to this, but the records themself are coming from outside - which makes it confusing for anyone looking at this file.

nearmax

comment created time in 9 days

issue commentnearprotocol/nearcore

Design EVM challenges

EVM doesn't have any state iteration. The only state iteration is done for removing subtree in state, via the same operation we use for deleting account. Whatever we are using for account deletion - we can leverage there.

nearmax

comment created time in 9 days

Pull request review commentnearprotocol/nearcore

WIP: EVM precompile

+use std::{+    cmp::{max, min},+    io::{self, Cursor, Read},+    mem::size_of,+};++use byteorder::{BigEndian, ByteOrder, LittleEndian, ReadBytesExt};+use ethereum_types::{Address, H256, U256};+use num_bigint::BigUint;+use num_traits::{FromPrimitive, One, ToPrimitive, Zero};+use parity_bytes::BytesRef;+use ripemd160::Digest;+use vm::{MessageCallResult, ReturnData};++#[derive(Primitive)]+enum Precompile {+    EcRecover = 1,+    Sha256 = 2,+    Ripemd160 = 3,+    Identity = 4,+    ModexpImpl = 5,+    Bn128AddImpl = 6,+    Bn128MulImpl = 7,+    Bn128PairingImpl = 8,+    Blake2FImpl = 9,+    LastPrecompile = 10,+}++pub fn is_precompile(addr: &Address) -> bool {+    *addr < Address::from_low_u64_be(Precompile::LastPrecompile.to_u64().unwrap())+}++pub fn precompile(id: u64) -> Result<Box<dyn Impl>, String> {+    Ok(match Precompile::from_u64(id) {+        Some(Precompile::EcRecover) => Box::new(EcRecover) as Box<dyn Impl>,+        Some(Precompile::Sha256) => Box::new(Sha256) as Box<dyn Impl>,+        Some(Precompile::Ripemd160) => Box::new(Ripemd160) as Box<dyn Impl>,+        Some(Precompile::Identity) => Box::new(Identity) as Box<dyn Impl>,+        Some(Precompile::ModexpImpl) => Box::new(ModexpImpl) as Box<dyn Impl>,+        Some(Precompile::Bn128AddImpl) => Box::new(Bn128AddImpl) as Box<dyn Impl>,+        Some(Precompile::Bn128MulImpl) => Box::new(Bn128MulImpl) as Box<dyn Impl>,+        Some(Precompile::Bn128PairingImpl) => Box::new(Bn128PairingImpl) as Box<dyn Impl>,

Damn, indeed it's updated. I've tried to update the version of EVM but the versions of all of the libraries didn't work... I guess need to do it to actually properly support.

ilblackdragon

comment created time in 9 days

PullRequestReviewEvent

push eventnearprotocol/nearcore

Illia Polosukhin

commit sha d21cb9c52140fc9e9869bfc88fd3dadb78fdee9d

Removing storage for given contract in EVM

view details

push time in 9 days

push eventilblackdragon/balancer-core

Illia Polosukhin

commit sha 21cba966adeef27ad1d1d0a3c3353f1c340744a0

Update version of near-web3-provider

view details

push time in 9 days

push eventnear/near-web3-provider

Illia Polosukhin

commit sha 3d16010cb362981849530fb2949280b4a7918353

Bind to near-api-js commit that has exported required classes

view details

push time in 9 days

push eventnear/near-cli

luciotato

commit sha 5a6a5cf9376d39931bdeb2ed7d6d4b4cfd2ea5f5

fix: small error in delete account param descr.

view details

Vladimir Grichina

commit sha 86cd16558c376395bdf8eba8bc15000fa63a39c2

Merge pull request #506 from luciotato/master fix: small error in delete account param descr.

view details

Vladimir Grichina

commit sha b3f5bde78451901d1e6cc8392e2ef2fc0bab23b9

Update CODEOWNERS

view details

Vladimir Grichina

commit sha 0ab9647f65a991e925095989bb3d8240535797dd

near-api-js@0.29.1

view details

Vladimir Grichina

commit sha c6870c5f30799cb8cdcdc55046edba792d37daa6

yarn.lock

view details

Illia Polosukhin

commit sha 5d199c330ef44e911bd4cdc204fa1d94046b386f

Merge remote-tracking branch 'origin/master' into generate-key

view details

Illia Polosukhin

commit sha ac854a48372eb305fd83d151842f323024762c7f

Undo add-key branch here

view details

Illia Polosukhin

commit sha 9f310e7003909d70648cd2ebe1bdd25bf17931ef

Move seed phrase into a middleware to allow other actions to work with it

view details

push time in 10 days

push eventnear/near-cli

luciotato

commit sha 5a6a5cf9376d39931bdeb2ed7d6d4b4cfd2ea5f5

fix: small error in delete account param descr.

view details

Vladimir Grichina

commit sha 86cd16558c376395bdf8eba8bc15000fa63a39c2

Merge pull request #506 from luciotato/master fix: small error in delete account param descr.

view details

Vladimir Grichina

commit sha b3f5bde78451901d1e6cc8392e2ef2fc0bab23b9

Update CODEOWNERS

view details

Vladimir Grichina

commit sha 0ab9647f65a991e925095989bb3d8240535797dd

near-api-js@0.29.1

view details

Vladimir Grichina

commit sha c6870c5f30799cb8cdcdc55046edba792d37daa6

yarn.lock

view details

Illia Polosukhin

commit sha d70f111684b2ba9aae35308796268e7cac84dee0

Merge remote-tracking branch 'origin/master' into add-key

view details

Illia Polosukhin

commit sha 3603f3207d18cba269db3c6f813d3b9c8f838b58

Redo the format of add/remove key to be <account-id> <key>

view details

push time in 10 days

push eventilblackdragon/balancer-core

Illia Polosukhin

commit sha 95ebca9d6d369731448322d31f41f49ab90210a6

Update link to near-web3-provider

view details

push time in 10 days

push eventnear/near-web3-provider

Mike Purvis

commit sha 86125efc2a95f66a8ecce875ea3f4ed6ad9a8824

remove three debugging logs

view details

Mike Purvis

commit sha ceb39ce3cfd5d4c39f057a558d45fd94a6c3d106

Merge pull request #59 from near/hotfix/remove-debug remove three debugging logs

view details

Illia Polosukhin

commit sha 76da2200b63091f5b7211e3909c7749ba5c248f1

Making test account creation parameterized by NearProvider configuration. Still might fail first time as there is way to wait

view details

Illia Polosukhin

commit sha 8f061e54e80a73a6346e829f54ae4adb5402ba5f

Add signTypedData method

view details

Illia Polosukhin

commit sha 8d767ebcdf942ecdf5636a63a538725f3c29ba6e

Lowercase hashes for finding them in accounts registry

view details

Illia Polosukhin

commit sha d9f5426a77582741f238a47174f0879ccab4b844

Merge remote-tracking branch 'origin/master' into precompile

view details

push time in 10 days

push eventnear/rainbow-bridge-lib

Alex Kouprin

commit sha 6020aecdd996676a72346780338c7ef8c69fa2c0

use token factory (#10)

view details

Illia Polosukhin

commit sha 9063c5eaef4453a4dceeeeed91456b066ba22eb7

Merge branch 'master' into utils

view details

push time in 10 days

push eventnear/core-contracts

Illia Polosukhin

commit sha c8503ce0aee7460c3cb0574e737a05b9750a816c

Updating to support of vesting post lockup

view details

push time in 10 days

Pull request review commentnearprotocol/nearcore

Evm gas estimation

 pub fn create_context<'a>(         false,     ) }++pub fn show_evm_gas_used(context: &EvmContext) {

or just move this inside #[cfg(tests)]

ailisp

comment created time in 11 days

Pull request review commentnearprotocol/nearcore

Evm gas estimation

 pub fn run_evm(                 used_gas: context.gas_counter.used_gas(),                 logs: context.logs,             };-            (Some(outcome), None)-        }-        Err(VMLogicError::EvmError(err)) => {-            (None, Some(VMError::FunctionCallError(FunctionCallError::EvmError(err))))+            (Some(outcome), None, context.evm_gas_counter.used_gas)

Hm, I'm curious how is this done in other places? Seems like this is wrong level where evm gas should be surfaced. And the normal gas is in the VMOutcome

ailisp

comment created time in 10 days

Pull request review commentnearprotocol/nearcore

Evm gas estimation

 impl EvmState for SubState<'_> {     } } +pub struct EvmGasCounter {+    pub used_gas: U256,+    pub max_gas: U256,+}++impl EvmGasCounter {+    pub fn new(used_gas: U256, max_gas: U256) -> EvmGasCounter {+        Self { used_gas, max_gas }+    }++    pub fn pay_gas(&mut self, amount: U256) {+        // TODO: return error if gas not sufficient+        self.used_gas += amount;+    }++    pub fn set_gas_left(&mut self, left: U256) {+        self.used_gas = self.max_gas - left;

saturated?

ailisp

comment created time in 10 days

Pull request review commentnearprotocol/nearcore

Evm gas estimation

 impl<'a> EvmContext<'a> {         self.add_balance(&sender, U256::from(self.attached_deposit))?;         let value =             if self.attached_deposit == 0 { None } else { Some(U256::from(self.attached_deposit)) };-        interpreter::call(self, &sender, &sender, value, 0, &contract_address, &input, true)-            .map(|rd| rd.to_vec())+        let rd = interpreter::call(+            self,+            &sender,+            &sender,+            value,+            0,+            &contract_address,+            &input,+            true,+            &self.evm_gas_counter.gas_left(),+        )?;+        match rd {+            MessageCallResult::Success(gas_left, data) => {

this deserves a

impl From<MessageCallResult> in Result<Vec<u8>>

It probably doesn't work this way though, because Result is an alias

ailisp

comment created time in 11 days

Pull request review commentnearprotocol/nearcore

Evm gas estimation

 impl<'a> EvmContext<'a> {         self.add_balance(&sender, U256::from(self.attached_deposit))?;         let value =             if self.attached_deposit == 0 { None } else { Some(U256::from(self.attached_deposit)) };-        interpreter::call(self, &sender, &sender, value, 0, &contract_address, &input, true)-            .map(|rd| rd.to_vec())+        let rd = interpreter::call(+            self,+            &sender,+            &sender,+            value,+            0,+            &contract_address,+            &input,+            true,+            &self.evm_gas_counter.gas_left(),+        )?;+        match rd {+            MessageCallResult::Success(gas_left, data) => {+                self.evm_gas_counter.set_gas_left(gas_left);+                Ok(data.to_vec())+            }+            MessageCallResult::Reverted(gas_left, data) => {+                self.evm_gas_counter.set_gas_left(gas_left);+                Err(VMLogicError::EvmError(EvmError::Revert(hex::encode(data.to_vec()))))+            }+            _ => unreachable!(),

hm, I'm always wary of unreachable...

ailisp

comment created time in 11 days

Pull request review commentnearprotocol/nearcore

Evm gas estimation

 pub fn create_context<'a>(         false,     ) }++pub fn show_evm_gas_used(context: &EvmContext) {

Implement Display or Debug for EvmContext instead?

ailisp

comment created time in 11 days

Pull request review commentnearprotocol/nearcore

Evm gas estimation

 use serde::export::fmt::Error; use serde::export::Formatter; use serde::{Deserialize, Serialize}; +use ethereum_types::U256;

spurious?

ailisp

comment created time in 11 days

Pull request review commentnearprotocol/nearcore

Evm gas estimation

 fn test_solidity_accurate_storage_on_selfdestruct() {     // Deploy CREATE2 Factory     let mut context = create_context(&mut fake_external, &vm_config, &fees_config, accounts(1), 0);     let factory_addr = context.deploy_code(hex::decode(&FACTORY_TEST).unwrap()).unwrap();+    show_evm_gas_used(&context);      // Deploy + SelfDestruct in one transaction     let salt = H256([0u8; 32]);     let destruct_code = hex::decode(&DESTRUCT_TEST).unwrap();     let input = create2factory::functions::test_double_deploy::call(salt, destruct_code.clone()).0;     let raw = context.call_function(encode_call_function_args(factory_addr, input)).unwrap();+    show_evm_gas_used(&context);

I'm assuming this is not for submission? Usually, it's better to have asserts instead of prints.

ailisp

comment created time in 11 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentnear/rainbow-bridge-cli

[Epic] System testing infrastructure

RE: near-api-js:

  • We should move all the robustness enhancements to near-api-js and add / leverage tests for them there.

RE: Key management:

  • Not passing secret key via command line is the start. We use ~/.near-credentials/<networkId> for managing keys in the near-shell and other tools should use the same pattern, for example - https://github.com/near/rainbow-bridge-lib/pull/12/files#diff-2b4ca49d4bb0a774c4d4c1672d7aa781R75

@mikedotexe wasn't researching alternatives to truffle to switch anything of ours - it was work to see which frameworks we need to support for EVM. I agree that buidler has nice features for debugging. I think truffle was adding them as well: https://www.trufflesuite.com/docs/truffle/getting-started/debugging-your-contracts#overview

can do truffle test --debug and use debug()

Switch to use yargs / configs

Current setting of commander and configstore for arg and config, is there a reason to switch yargs and configs?

I don't really know the difference, but we should not have this file - https://github.com/near/rainbow-bridge-lib/blob/master/config/index.js. This looks like we are implementing something that have been already implemented times and times again. This file is not tested as far as I can see and if nothing else has clear issues with error propagation. But might have other bugs.

we have the first two.

I see a single test "should be ok" in all contracts:

  • https://github.com/near/rainbow-bridge-sol/blob/master/nearbridge/test/NearBridge.js
  • https://github.com/near/rainbow-bridge-sol/blob/master/token-locker/test/TokenLocker.js <- this doesn't test much

I don't see tests that check that connector work on it's own. Can you point me to it?

We have these.

I don't actually see tests, I see a deployment and usage scripts. Which also involve a strange on-disk state machine - which @Kouprin took a fair bit of time to realize is happening. (strange - because no real use case can use this, as most of the usage will not have access to a disk)

Here is example of integration tests that I suggest (obviously not done and doesn't have edge cases / error handling):

  • https://github.com/near/rainbow-token-connector/pull/1/files#diff-b182b90185fdf3a9336fbd92708d2fd9R89
  • instructions how to run these tests: https://github.com/near/rainbow-token-connector/pull/1/files#diff-04c6e90faac2675aa89e2176d2eec7d8R136

We just missing an easy way to install neard via apt/brew (I guess can be done via nearup, unless we changed that)

Kouprin

comment created time in 10 days

PR opened near/core-contracts

Adding hash for vesting schedule
+81 -77

0 comment

6 changed files

pr created time in 10 days

create barnchnear/core-contracts

branch : hashed-vesting

created branch time in 10 days

push eventnear/core-contracts

Illia Polosukhin

commit sha 3c8388e36cd58e285da97ecd3e11d31026083bcc

Adding first integration test for multisig (#103)

view details

push time in 10 days

PR merged near/core-contracts

Adding integration tests for multisig

Using my test library for concise test.

+1816 -134

0 comment

3 changed files

ilblackdragon

pr closed time in 10 days

Pull request review commentnearprotocol/nearcore

Evm gas estimation

-nightly-2020-05-15+nightly-2020-08-26

this is very unexpected to do this in this PR

ailisp

comment created time in 11 days

PullRequestReviewEvent

push eventnear/rainbow-token-connector

Illia Polosukhin

commit sha c99ed789c28d4859be4e08eeb6c9264c6fd114f9

Remove package lock

view details

push time in 11 days

pull request commentnear/rainbow-token-connector

Adding tests and library to use connectors

It's not the problem with version. Your internet is very different from my internet. I'll remove the package-lock.json for now.

ilblackdragon

comment created time in 11 days

push eventilblackdragon/balancer-core

Illia Polosukhin

commit sha 4841f808049a4963ed7fc3a7b8f193f64b3bfc80

Clean up test account creation

view details

Illia Polosukhin

commit sha b92db6cd1a75bd4f17c3497b8879ffbaf44d2f46

Change testnet to test network with precompile

view details

push time in 11 days

push eventnearprotocol/nearcore

Bowen Wang

commit sha 89dde8c427afc36b66bccb76306cc34773430ca3

fix: optimize build_receipt_hashes (#3235) Optimize `build_receipt_hashes` to avoid unnecessary hash computation and cloning. Test plan --------- `test_build_receipt_hashes` to make sure that the protocol doesn't change.

view details

Illia Polosukhin

commit sha 01045f270c5646a0f9be8251a1638a9d2ea8109f

Adding unwrap_or around time to not fail when time goes back on the laptop

view details

Illia Polosukhin

commit sha 04ec1ca3e8b5825a9ad04f445b2f66af8a90e096

Merge remote-tracking branch 'origin/master' into evm-precompile

view details

Illia Polosukhin

commit sha e5f3c123fbcb9968035583a7b19fbc8b7e10e1dd

Fix overflow / under-delete in overwrite_storage

view details

push time in 12 days

PR opened near/rainbow-bridge-lib

Adding utils and fixing other stuff
+5235 -94

0 comment

14 changed files

pr created time in 13 days

push eventnear/rainbow-token-connector

Illia Polosukhin

commit sha 620ad3e45f9f722d77f88a7a39b252d5a4ead9ef

Proof extraction for eth->near deposit

view details

push time in 13 days

push eventnear/rainbow-bridge-lib

Illia Polosukhin

commit sha 9636c9ef6a4b9cc2231494d29a91c185d89bb543

signAndSendTransaction propagate the error message

view details

push time in 13 days

push eventnear/rainbow-bridge-lib

Illia Polosukhin

commit sha d25bfac34a05c78d6558e64b9f3eeb42db797aea

Keep adding useful tools for bridge-token integration

view details

push time in 13 days

push eventnear/rainbow-token-connector

Illia Polosukhin

commit sha b0d4e2736b6b4df132f4d311876d43e2cdb31450

Adding functions to create BridgeToken wrappers with deployment

view details

push time in 13 days

pull request commentnear/rainbow-token-connector

Adding tests and library to use connectors

I have no idea, but because my internet is somewhat not stable, sometimes one of them doesn't work.

ilblackdragon

comment created time in 13 days

issue openednear/near-api-js

Error from transaction printed doesn't have any detail

Describe the bug Currently printLogsAndFailures doesn't show any detail about error. Usually it's something like Error: {"index":0}

Expected behavior TransactionResult contains status.Failure with detail information. Currently the way the information gets extracted is broken.

created time in 13 days

PR opened near/rainbow-token-connector

Adding tests and library to use connectors

Testing NEAR <> Ethereum token connector, while using Mock prover on both sides.

This starts to use rainbow-bridge-lib for various tools and components.

+13502 -13

0 comment

13 changed files

pr created time in 13 days

create barnchnear/rainbow-token-connector

branch : add-testing

created branch time in 13 days

create barnchnear/rainbow-bridge-lib

branch : utils

created branch time in 13 days

push eventnear/rainbow-bridge-lib

Illia Polosukhin

commit sha 5adfa680adbf1a982d12fab3be482575b8ff83c3

Adding mint action to make sure account has balance for tests

view details

push time in 13 days

pull request commentnearprotocol/NEPs

Native EVM

Also good question if we want to restrict creation of EVM accounts. E.g. if we define anything under ".evm" to be an EVM account, should we limit creation of such accounts?

Current suggestion to add a "registrar" method to EVM, that will create sub-account if account_id == "evm":

   fn create_account(&self, name: String) -> Result<()> { 
      if self.account_id != "evm" return EvmError::AccountCreationOnlyTopLevel();
      Promise::new(format!("{}.evm", name)).create_account().transfer(self.attached_deposit);
   }
ilblackdragon

comment created time in 14 days

pull request commentnearprotocol/NEPs

Native EVM

EcRecover handling

Context: there is a pattern of meta-transactions on Ethereum that leverages next flow:

  • User signs a message '\x19Ethereum message:\n' || len(bytes) || bytes -- this is supported by all the major wallets
  • User sends such message and signature to a relayer
  • Relayer usually is some operator (exchange operator) or just a "gas station network"
  • Relayer takes this messages, creates Ethereum transaction and send it over to Ethereum network
  • The receiving contract then verifies the message and uses ecrecover from signature to determine the public_key that signed it. From public_key the address is inferred and this address used as initiator of the action.
  • In case of exchanges, this is usually sent to the exchange contract. Such contract would settle the trades on behalf of inferred address or withdraw funds to their address.
  • In case of more general gas station, it would extract a method/args and call a contract on behalf of the inferred address. This requires modifying the receiving contract to use custom method for msg.sender.

How will NEAR EVM handle this:

  • This will be only supported for secp256k1 key pairs. E.g. if message is signed with ed25519, the ecrecover will fail.
  • We are adding support for Ethereum addresses, e.g. secp256k1's public_key[..20] is a valid address inside NEAR's EVM.
  • These addresses will be accessible/used if NEAR transaction signer_pk is secp256k1 (e.g. in this cases signer_id will be ignored)
  • We add an option to send meta-transaction directly to EVM "contract". E.g. a format of message '\x19Ethereum message:\n' || len || contract_address || method_name || args, which calls a contract address on behalf of the user (e.g. msg.sender == ecrecover(signature)`.

Some Cases that this handles

  • Frontend with key management signs on user's behalf and sends to operator. Operator signs tx and sends to the contract. Contract ercrecover(signature) to determine address of the user to attach action to.
  • User signs a message in Metamask and sends it to the app. App's backend relays it to the NEAR network via EVM and action gets executed on the behalf of this user. Financially, this should include that action also pays to the relayer/app something (but can be something like deposit to exchange where exchange would get money in some other way).
  • User signs a message in Metamask and sends it to exchange backend. Exchange backend relays it to an exchange contract in NEAR EVM. Exchange contract ecrecover(signature) and depending on the message makes an action on behalf of the user.
ilblackdragon

comment created time in 14 days

pull request commentnearprotocol/NEPs

Adding implicit account creation

@evgenykuzyakov when you have a minute can you update this PR with the current design and merge this? So we have nomicon up to date.

ilblackdragon

comment created time in 14 days

issue commentnear/rainbow-bridge-cli

[Epic] System testing infrastructure

So my suggestion to structure things (including a bunch of other related issues):

  • Don't use classes where classes are not needed. Remove extra folders. If class is 1 method or 1 initializer and 1 run - it should not be a class.
  • Add utilities, like remove0x also use web3.utils that have a rich set of things
  • Replace maybe create account, etc with near-api-js APIs for all this
  • Leverage NEAR's key management. Do similar thing for ethereum.
  • Switch to use yargs / configs
  • Use truffle artifacts to locate artifacts like abi/bin instead of managing them manually.

Principle to follow is that we can test things on every level. E.g.

  • contracts should be tested by themself first.
  • then test that connectors work with each other with mocked provers
  • then test that relayers can independently work

lib: index.js (exports everything from src) src/ borsh.js // ideally use nearAPI.utils.serialize instead of own version of borsh proof-extrator.js
contract-management.js // functions to deploy ethereum and near client & prover contracts test/ bridge.test.js proof-extractor.test.js

Because relayers right now can not live in lib, keep them in cli. But any logic (like iterating over blocks, contract management, transformations, etc) should got to lib

cli: bin/ rainbow-cli.js middleware/ key-store.js services/ eth2near-relay.js // relayer of Eth blocks to NEAR near2eth-relay.js // relayer of NEAR blocks to Eth watchdog.js // watchdog for validity of NEAR blocks on ETH test/ eth2near.test.js near2eth.test.js

Local testing:

  • one command to run default local near node
  • one command to run default ganache
  • run any test - should work

Remote testing: export NEAR_ENV=testnet run any test - should work

Kouprin

comment created time in 14 days

issue commentnear/rainbow-bridge-cli

Rainbow Config refactoring

Also should replace the argument stuff with yargs.

So in general something like this:

config.js:


function getConfig(env) {
    switch (env) {
        case 'mainnet':
            return {
                networkId: 'mainnet',
                nearNodeUrl: 'https://rpc.mainnet.near.org',
                ethNodeUrl: '',
            };
        case 'testnet':
            return {
                networkId: 'default',
                nearNodeUrl: 'https://rpc.testnet.near.org',
                ethNodeUrl: '',
            };
        case 'local':
            return {
                networkId: 'local',
                nearNodeUrl: 'http://localhost:3030',
                ethNodeUrl: 'http://localhost:',
                keyPath: `${process.env.HOME}/.near/local/validator_key.json`,
                masterAccount: 'test.near',
                nearEthClientId: 'client.test.near',
                nearEthProverId: 'prover.test.near',
            };
        default:
            throw Error(`Unconfigured environment '${env}'. Can be configured in src/config.js.`);
    }
}

module.exports = getConfig;

bin/rainbow-cli.js:

let config = require('../config')(process.env.NEAR_ENV || 'local');
yargs
    .strict()
    .scriptName('rainbow-cli')
    .option('nearNodeUrl', {
        desc: 'NEAR node URL',
        type: 'string',
        default: config.nearNodeUrl
    })
    .option('ethNodeUrl', {
        desc: 'ETH node URL',
        type: 'string',
        default: config.ethNodeUrl
    })
    .option('networkId', {
        desc: 'NEAR network ID, allows using different keys based on network',
        type: 'string',
        default: config.networkId
    })
    .option('masterAccount', {
        desc: 'NEAR master account',
        type: 'string',
        default: config.masterAccount
    })
    .option('keyPath', {
        desc: 'Key path for NEAR master account',
        type: 'string',
        default: config.masterAccount
    })
    .option('nearEthClientId', {
        desc: 'Account Id Ethereum Client on NEAR',
        type: 'string',
        default: config.nearEthClientId
    })
    .option('nearEthProverId', {
        desc: 'Account Id Ethereum Prover on NEAR',
        type: 'string',
        default: config.nearEthProverId
    })
    .middleware(require('../middleware/key-store'))
    .command(setupBridge)
    .config(config)
    .wrap(null)
    .argv;
Kouprin

comment created time in 14 days

push eventnear/rainbow-token-connector

Illia Polosukhin

commit sha 0f874679dc534bfe9cbe8092584a5594a299fda1

Lower case hex addresses in deploy contract

view details

push time in 14 days

push eventnear/rainbow-token-connector

Illia Polosukhin

commit sha f9290991cd4d746a77d829e81cb4f8ae8cd6be2b

Change event name to Withdraw, add a bit more conditions to tests.

view details

push time in 14 days

pull request commentnearprotocol/nearcore

WIP: EVM precompile

Yes, this allows any number of EVMs. I suggest we use "*.evm" namespace for all the EVMs though.

ilblackdragon

comment created time in 15 days

push eventnear/rainbow-token-connector

Illia Polosukhin

commit sha 9f0e81d03eb4d9ffdd64897152a4151b2a8065e7

Add sol withdraw test

view details

push time in 15 days

push eventnear/rainbow-bridge-sol

Illia Polosukhin

commit sha 99531214ca5cb4a53f016f47cb20ba35ca03cdc1

Fix in Borsh deserialization: extra shift in decodeBytes20

view details

push time in 15 days

push eventnear/rainbow-token-connector

Illia Polosukhin

commit sha a72c872fe14b21c99c02ee26c74430ba4eaf8d87

Update tests for sol; Fix issues relevant issues in contracts

view details

push time in 15 days

Pull request review commentnear/near-cli

Enchancing Generate key

+const exitOnError = require('../utils/exit-on-error');+const connect = require('../utils/connect');+const inspectResponse = require('../utils/inspect-response');+const { utils } = require('near-api-js');++module.exports = {

yep, I just branched from that PR.

ilblackdragon

comment created time in 15 days

PullRequestReviewEvent

startednear/rainbow-bridge-lib

started time in 15 days

push eventnear/rainbow-token-connector

Illia Polosukhin

commit sha 0294289acdb5b7a42bfa6da8394d96ee0f7a7756

Rebuild contracts

view details

push time in 15 days

push eventnear/rainbow-token-connector

Illia Polosukhin

commit sha 86e1e06c904fb594d6c94a2178f87bad70a72a03

Add lock token test to Solidity

view details

push time in 15 days

push eventnear/rainbow-token-connector

Illia Polosukhin

commit sha 651ebb6b0ca3a3b0e5fae96f1d01ef36f100a4eb

Rename erc20locker to erc20connector. Add BridgeTokenFactory on top of just simple locker for NEAR->ETH transfers

view details

push time in 15 days

pull request commentnear/near-cli

Feature: Add 2FA Support to CLI

Is there a way to not need --2fa flag? Ideally we should figure out it from account itself.

Multisig is easily detectable. Not sure if we want to expose CH to tell if this account is managed by it or not - looks a bit like of privacy/attack issue.

Also Account object should work not just specifically to 2fa but for any multisig account. This probably can even live in near-api-js eventually.

And 2FA should be just extra wrapper over Account that if it's 2fa account - after request was created it will wait for confirmation and query for result after tx confirmed.

mattlockyer

comment created time in 15 days

issue openednear/near-cli

Add support for near drops to CLI

There are two things:

  • Creation of near drop
$ near create-drop --amount <amount> --accountId <originating account> --escrow near
Outputs https://wallet.near.org/...

where --escrow defaults to near.

  • Claiming near drop:
$ near claim-drop <account-id> <public-key> <link>

Alternatively, link can be added as an option to create-account. On the other hand, one can claim it into existing account, so claim-drop can support that, which would make public-key optional if account already exists.

created time in 15 days

issue commentnear/bounties

Extend create-near-app to create CLI tools for smart contracts | Bounty: $2000 USD in NEAR

@luciotato are you planning to work on this bounty? If yes, do you need any input on our side?

I like your suggestions on "100N" vs "100yN". Also generally, I think we should use N everywhere by default. The yoctoNEAR are right now in arguments - because those arguments are raw data going to blockchain. But CLI should wrap that for sure.

ilblackdragon

comment created time in 16 days

issue closednear/bounties

Benchmarking NEAR's network | Bounty: 2000 NEAR

Describe your idea or initiative here

Leverage existing scripts to run 100 node network across the globe and build robust benchmarking tools with various loads (create lots of accounts, transfers, smart contracts, etc).

Bounty

2000 $NEAR

closed time in 16 days

ilblackdragon

issue commentnear/bounties

Benchmarking NEAR's network | Bounty: 2000 NEAR

Have been implemented internally on the "mixnet".

ilblackdragon

comment created time in 16 days

more