Federated Node Provisioning
Production
Here are the recommendations and/or requirements when setting up a production-grade Counterblock Federated Node:
Server Hardware/Network Recommendations:
Xeon E3+ or similar-class processor
16GB+ RAM (ECC)
Disk drives in RAID-1 (mirrored) configuration (SSD prefered)
Hosted in a secure data center with physical security and access controls
DDOS protection recommended if you will be offering your service to others
** Disk Space Requirements ** The exact disk space required will be dependent on what services are run on the node:
* Base System: **20GB** (to be safe)
* ``counterpartyd``, ``counterblockd`` databases: **~200MB**
* ``insight``: **~30GB** (mainnet), **~3GB** (testnet)
* ``armory_utxsvr``: **~25GB** (mainnet), **~3GB** (testnet)
Generally, we recommend building on a server with at least 120GB of available disk space.
User Configuration
Note that when you set up a federated node, the script creates two new users on the system: xcp and xcpd. (The xcp user also has an xcp group created for it as well.)
The script installs counterpartyd, counterwallet, etc into the home directory of the xcp user. This user also owns all installed files. However, the daemons (i.e. bitcoind, insight, counterpartyd, counterblockd, and nginx) are actually run as the xcpd user, which has no write access to the files such as the counterwallet and counterpartyd source code files. The reason things are set up like this is so that even if there is a horrible bug in one of the products that allows for a RCE (or Remote Control Exploit), where the attacker would essentially be able to gain the ability to execute commands on the system as that user, two things should prevent this:
The xcpd user doesn't actually have write access to any sensitive files on the server (beyond the log and database files for bitcoind, counterpartyd, etc.)
The xcpd user uses /bin/false as its shell, which prevents the attacker from gaining shell-level access
This setup is such to minimize (and hopefully eliminate) the impact from any kind of potential system-level exploit.
sudo python3 setup_federated_node.py
We skip installing the NodeJS version, since the repository is outdated.
From this link we take the old Bitcoin daemon.
https://bitcoin.org/bin/insecure/bitcoin-core-0.9.2.1/
The 0.9.0 release of Bitcoin Core added a new standard transaction type granting access to a previously disallowed script function, OP_RETURN. This function accepts a user-defined sequence of up to 40 bytes. When a transaction containing a challenge script with an OP_RETURN function is mined into a block, the accompanying byte sequence enters the block chain.
Changes in Counterpartyd_build setup_federated_node.py
sudo rm /etc/apt/sources.list.d/mongodb*.list
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927
echo "deb http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.2.list
sudo apt-get update
>>Reading package lists... Done
>>W: GPG error: http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.2 >>Release: The following signatures couldn't be verified because the public key >>is not available: NO_PUBKEY D68FA50FEA312927
>>E: The repository 'http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.2 >>Release' is not signed.
>>N: Updating from such a repository can't be done securely, and is therefore >>disabled by default.
>>N: See apt-secure(8) manpage for repository creation and user configuration >>details.
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv D68FA50FEA312927
>>gpg: key D68FA50FEA312927: public key "MongoDB 3.2 Release Signing Key >><packaging@mongodb.com>" imported
>>gpg: Total number processed: 1
>>gpg: imported: 1
sudo apt-get update
sudo apt install mongodb-org
cd ¬/counterpartyd_build
sudo python3 setup.py --with-counterblockd
Commits on Mar 6, 2024 mongodb v 3.2.22
https://github.com/Ignat99/counterpartyd_build/commit/eb8662eb6bd7676decb7cbebf6f5920ea880c2d4
Error during the package build process Сounterblockd
Running setup.py install for gevent ... error
2024-03-06 14:09:48,939|ERROR: Command failed: '/home/user/counterpartyd_build/env.counterblockd/bin/pip install -r /home/user/counterpartyd_build/dist/counterblockd/pip-requirements.txt'
including stdio.h and sys/types.h.
https://github.com/gevent/gevent/commit/3ab69f263dcf9e3b59d8ab7e6bd0b8e521fea771
/* CARES_PULL_SYS_TYPES_H is defined above when inclusion of header file */
/* sys/types.h is required here to properly make type definitions below. */
#ifdef CARES_PULL_SYS_TYPES_H
# include <sys/types.h>
#endif
The problem was solved by moving to the next version 1.2.0. It's all about this piece of code. This piece of code is compiled by Cython. The scripting language is translated into C and then assembled. This was how performance was achieved before Rust was invented.
https://github.com/Ignat99/counterblockd/commit/dfb273ae3de26ffc748d051252fd5972fc9b0df5
Some issue with old python pytest related packages:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
pytest-cov 2.11.1 requires pytest>=4.6, but you have pytest 2.5.1 which is incompatible.
tweepy 3.10.0 requires requests[socks]>=2.11.1, but you have requests 2.3.0 which is incompatible.
passnfly 0.1.1 requires Flask~=1.1.2, but you have flask 0.10.1 which is incompatible.
Change version and server of NodeJS
https://www.ubuntuupdates.org/ppa/nodejs_10.x
Change version insight-api 0.3.1 and NodeJS to 13.14.0 (Possible up to 18.x with old bitcoin backend) https://github.com/Ignat99/counterpartyd_build/commit/f2ebb7504ab72b718606c70f92b2895c851c33b4
Nginx issue
An outdated web server is used here. The main disadvantage of all these solutions is the old SSL. There was vulnerability in him. But you can turn this disadvantage into an advantage by replacing the block stream cipher in closed networks with your own. In any case, you will need to do a survey of ALL free and open source packages.
E: Unable to locate package nginx-openresty
2024-03-08 11:26:01,798|ERROR: Command failed: 'apt-get -y remove nginx-openresty'
https://groups.google.com/g/openresty-en?pli=1
OpenResty® is a full-fledged web platform that integrates our enhanced version of the Nginx core, our enhanced version of LuaJIT, many carefully written Lua libraries, lots of high quality 3rd-party Nginx modules, and most of their external dependencies. It is designed to help developers easily build scalable web applications, web services, and dynamic web gateways.
wget http://openresty.org/download/ngx_openresty-1.2.6.6.tar.gz
tar -zxvf ngx_openresty-1.2.6.6.tar.gz
cd ngx_openresty-1.2.6.6
https://github.com/Ignat99/counterpartyd_build/commit/58fff8fc51157578f07789d1d0c8e4f07db5d7a9
W: GPG error: https://apt.newrelic.com/debian newrelic Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B31B29E5548C16BF
E: The repository 'http://apt.newrelic.com/debian newrelic Release' is not signed.
This company even offered me a job after a seminar in Barcelona. The licenses and their agent versions are already outdated. Now all the functions of their product such as Server Dashboard can be assembled quite quickly from free and open source software.
Error of JSON with version Blockchain
Traceback (most recent call last):
File "/home/xcp/counterpartyd_build/env/lib/python3.6/site-packages/requests/adapters.py", line 327, in send
timeout=timeout
File "/home/xcp/counterpartyd_build/env/lib/python3.6/site-packages/requests/packages/urllib3/connectionpool.py", line 520, in urlopen
raise SSLError(e)
requests.packages.urllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852)
During handling of the above exception, another exception occurred:
Fix:
https://raw.githubusercontent.com/Ignat99/counterpartyd/master/version.json
Problem connect to bitcoind
Traceback (most recent call last):
File "/home/xcp/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 1132, in <module>
blocks.follow(db)
File "/home/xcp/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 1292, in follow
block_count = bitcoin.get_block_count()
File "/home/xcp/counterpartyd_build/dist/counterpartyd/lib/bitcoin.py", line 77, in get_block_count
return int(rpc('getblockcount', []))
File "/home/xcp/counterpartyd_build/dist/counterpartyd/lib/bitcoin.py", line 165, in rpc
raise exceptions.BitcoindRPCError('Cannot communicate with {} Core. ({} is set to run on {}, is {} Core?)'.format(config.BTC_NAME, config.XCP_CLIENT, network, config.BTC_NAME))
lib.exceptions.BitcoindRPCError: Cannot communicate with Bitcoin Core. (counterpartyd is set to run on mainnet, is Bitcoin Core?)
Listen http server RPC problem
New form of BLOCK_FIRST_TESTNET
Fix: add tx_info in txlist_hash, merge new_consensus_checks, fix config and previous merge, continue instead exception
Counterpartyd interfaces
user@ign:~/counterpartyd_build$ sudo su -s /bin/bash -c 'counterpartyd --data-dir=/home/xcp/.config/counterpartyd-testnet --testnet' xcpd
Status: Connecting to database.
Status: Running v9.45.0 of counterpartyd.
usage: counterpartyd [-h] [-V] [-v] [--testnet] [--testcoin]
[--carefulness CAREFULNESS] [--unconfirmed]
[--encoding ENCODING] [--fee-per-kb FEE_PER_KB]
[--regular-dust-size REGULAR_DUST_SIZE]
[--multisig-dust-size MULTISIG_DUST_SIZE]
[--op-return-value OP_RETURN_VALUE] [--unsigned]
[--data-dir DATA_DIR] [--database-file DATABASE_FILE]
[--config-file CONFIG_FILE] [--log-file LOG_FILE]
[--backend-rpc-connect BACKEND_RPC_CONNECT]
[--backend-rpc-port BACKEND_RPC_PORT]
[--backend-rpc-user BACKEND_RPC_USER]
[--backend-rpc-password BACKEND_RPC_PASSWORD]
[--backend-rpc-ssl] [--backend-rpc-ssl-verify]
[--blockchain-service-name BLOCKCHAIN_SERVICE_NAME]
[--blockchain-service-connect BLOCKCHAIN_SERVICE_CONNECT]
[--rpc-host RPC_HOST] [--rpc-port RPC_PORT]
[--rpc-user RPC_USER] [--rpc-password RPC_PASSWORD]
[--rpc-allow-cors]
{server,send,order,btcpay,issuance,broadcast,bet,dividend,burn,cancel,callback,rps,rpsresolve,publish,balances,asset,wallet,pending,reparse,rollback,market}
...
the reference implementation of the Counterparty protocol
positional arguments:
{server,send,order,btcpay,issuance,broadcast,bet,dividend,burn,cancel,callback,rps,rpsresolve,publish,balances,asset,wallet,pending,reparse,rollback,market}
the action to be taken
server run the server
send create and broadcast a *send* message
order create and broadcast an *order* message
btcpay create and broadcast a *BTCpay* message, to settle an
Order Match for which you owe BTC
issuance issue a new asset, issue more of an existing asset or
transfer the ownership of an asset
broadcast broadcast textual and numerical information to the
network
bet offer to make a bet on the value of a feed
dividend pay dividends to the holders of an asset (in
proportion to their stake in it)
burn destroy {} to earn XCP, during an initial period of
time
cancel cancel an open order or bet you created
callback callback a fraction of an asset
rps open a rock-paper-scissors like game
rpsresolve resolve a rock-paper-scissors like game
publish publish arbitrary data in the blockchain
balances display the balances of a Counterparty address
asset display the basic properties of a Counterparty asset
wallet list the addresses in your backend wallet along with
their balances in all Counterparty assets
pending list pending order matches awaiting BTCpayment from
you
reparse reparse all transactions in the database
rollback rollback database
market fill the screen with an always up-to-date summary of
the Counterparty market
optional arguments:
-h, --help show this help message and exit
-V, --version show program's version number and exit
-v, --verbose sets log level to DEBUG instead of WARNING
--testnet use Bitcoin testnet addresses and block numbers
--testcoin use the test Counterparty network on every blockchain
--carefulness CAREFULNESS
check conservation of assets after every CAREFULNESS
transactions (potentially slow)
--unconfirmed allow the spending of unconfirmed transaction outputs
--encoding ENCODING data encoding method
--fee-per-kb FEE_PER_KB
fee per kilobyte, in BTC
--regular-dust-size REGULAR_DUST_SIZE
value for dust Pay‐to‐Pubkey‐Hash outputs, in BTC
--multisig-dust-size MULTISIG_DUST_SIZE
for dust OP_CHECKMULTISIG outputs, in BTC
--op-return-value OP_RETURN_VALUE
value for OP_RETURN outputs, in BTC
--unsigned print out unsigned hex of transaction; do not sign or
broadcast
--data-dir DATA_DIR the directory in which to keep the database, config
file and log file, by default
--database-file DATABASE_FILE
the location of the SQLite3 database
--config-file CONFIG_FILE
the location of the configuration file
--log-file LOG_FILE the location of the log file
--backend-rpc-connect BACKEND_RPC_CONNECT
the hostname or IP of the backend bitcoind JSON-RPC
server
--backend-rpc-port BACKEND_RPC_PORT
the backend JSON-RPC port to connect to
--backend-rpc-user BACKEND_RPC_USER
the username used to communicate with backend over
JSON-RPC
--backend-rpc-password BACKEND_RPC_PASSWORD
the password used to communicate with backend over
JSON-RPC
--backend-rpc-ssl use SSL to connect to backend (default: false)
--backend-rpc-ssl-verify
verify SSL certificate of backend; disallow use of
self‐signed certificates (default: false)
--blockchain-service-name BLOCKCHAIN_SERVICE_NAME
the blockchain service name to connect to
--blockchain-service-connect BLOCKCHAIN_SERVICE_CONNECT
the blockchain service server URL base to connect to,
if not default
--rpc-host RPC_HOST the IP of the interface to bind to for providing JSON-
RPC API access (0.0.0.0 for all interfaces)
--rpc-port RPC_PORT port on which to provide the counterpartyd JSON-RPC
API
--rpc-user RPC_USER required username to use the counterpartyd JSON-RPC
API (via HTTP basic auth)
--rpc-password RPC_PASSWORD
required password (for rpc-user) to use the
counterpartyd JSON-RPC API (via HTTP basic auth)
--rpc-allow-cors Allow ajax cross domain request
The configuration we are checking:
sudo python3 setup_federated_node.py
2024-03-06 16:35:12,944|DEBUG: answered_questions: {'op': 'r', 'role': 'counterpartyd_only', 'branch': 'feature', 'run_mode': 't', 'backend_rpc_mode': 'b', 'blockchain_service': 'i', 'counterpartyd_public': 'y', 'counterwallet_support_email': None, 'security_hardening': 'n', 'autostart_services': 'y'}
Successfully launched service
2024-03-08 12:24:24,753|INFO: Counterblock Federated Node Build Complete (whew).
2024-03-08 12:24:24,754|DEBUG: RUNNING COMMAND: rm -f /etc/service/bitcoind-testnet/down
2024-03-08 12:24:24,759|DEBUG: RUNNING COMMAND: rm -f /etc/service/insight-testnet/down
2024-03-08 12:24:24,763|DEBUG: RUNNING COMMAND: rm -f /etc/service/counterpartyd-testnet/down
2024-03-08 12:24:24,767|DEBUG: RUNNING COMMAND: rm -f /etc/service/counterblockd/down
2024-03-08 12:24:24,770|DEBUG: RUNNING COMMAND: rm -f /etc/service/counterblockd-testnet/down
Starting the system
Start the bitcoind
sudo sv start bitcoind
sudo sv start bitcoind-testnet
sudo tail -f ~xcp/.bitcoin/debug.log
sudo tail -f ~xcp/.bitcoin-testnet/testnet3/debug.log
sudo sv start insight
sudo sv start insight-testnet
sudo tail -f ~xcp/insight-api/log/current
sudo tail -f ~xcp/insight-api/log-testnet/current
Then, watching these logs, wait for the insight sync (as well as the bitcoind sync and counterpartyd syncs) to finish, which should take between 7 and 12 hours. After this is all done, reboot the box for the new services to start (which includes both counterpartyd and counterblockd).
counterblockd, after starting up must then sync to counterpartyd. It will do this automatically, and the process will take between 20 minutes to 1 hour most likely. You can check on the status of counterblockd's sync using:
sudo tail -f ~xcp/.config/counterblockd/counterblockd.log
sudo tail -f ~xcp/.config/counterblockd-testnet/counterblockd.log
Also, you can start up the daemons in the foreground, for easier debugging, using the following sets of commands:
#bitcoind
sudo su -s /bin/bash -c 'bitcoind -datadir=/home/xcp/.bitcoin' xcpd
sudo su -s /bin/bash -c 'bitcoind -datadir=/home/xcp/.bitcoin-testnet' xcpd
#counterpartyd & counterblockd mainnet
sudo su -s /bin/bash -c 'counterpartyd --data-dir=/home/xcp/.config/counterpartyd' xcpd
sudo su -s /bin/bash -c 'counterblockd --data-dir=/home/xcp/.config/counterblockd -v' xcpd
#counterpartyd & counterblockd testnet
sudo su -s /bin/bash -c 'counterpartyd --data-dir=/home/xcp/.config/counterpartyd-testnet --testnet' xcpd
sudo su -s /bin/bash -c 'counterblockd --data-dir=/home/xcp/.config/counterblockd-testnet --testnet -v' xcpd
Start the Counterpartyd
sudo sv start counterpartyd
sudo sv start counterpartyd-testnet
sudo tail -f ~xcp/.config/counterpartyd/counterpartyd.log
sudo tail -f ~xcp/.config/counterpartyd-testnet/counterpartyd.testnet.log
Counterparty testnet faucet
Bitcoin testnet3 faucet
Compatibility with Ethereum's Smart Contracts
"""
This module tests for compability with Ethereum's Smart Contracts.
"""
15/Jan/2015
v9.49.4rc3
This is an example of a smart contract and a link to the first mention and version number counterpartyd.
rename contracts_test, only new OP_RETURN data are obfuscated, fixes + update testnet checkpoints
Transaction Encodings
In the general Bitcoin protocol, the parameter OP_RETURN was only 40 bytes long.
By default the default value of the encoding parameter detailed above is auto, which means that counterparty-server automatically determines the best way to encode the Counterparty protol data into a new tranaction. If you know what you are doing and would like to explicitly specify an encoding:
To return the transaction as an OP_RETURN transaction, specify opreturn for the encoding parameter.
OP_RETURN transactions cannot have more than 80 bytes of data. If you force OP_RETURN encoding and your transaction would have more than this amount, an exception will be generated.
To return the transaction as a multisig transaction, specify multisig for the encoding parameter.
pubkey should be set to the hex-encoded public key of the source address.
Note that with the newest versions of Bitcoin (0.12.1 onward), bare multisig encoding does not reliably propagate. More information on this is documented here.
To return the transaction as a pubkeyhash transaction, specify pubkeyhash for the encoding parameter.
pubkey should be set to the hex-encoded public key of the source address.
Advanced create_ parameters
Create_bet
Create_broadcast
Create_btcpay
Create_burn
Create_cancel
Create_dividend
Create_issuance
Create_order
Create_send
Each create_ call detailed below can take the following common keyword parameters:
encoding (string): The encoding method to use, see transaction encodings for more info.
pubkey (string/list): The hexadecimal public key of the source address (or a list of the keys, if multi‐sig). Required when using encoding parameter values of multisig or pubkeyhash. See transactions encoding for more info
allow_unconfirmed_inputs (boolean): Set to true to allow this transaction to utilize unconfirmed UTXOs as inputs. Defaults to false.
fee (integer): If you’d like to specify a custom miners’ fee, specify it here (in satoshi). Leave as default for the server to automatically choose.
fee_per_kb (integer): The fee per kilobyte of transaction data constant that the server uses when deciding on the dynamic fee to use (in satoshi).
fee_provided (integer): If you would like to specify a maximum fee (up to and including which may be used as the transaction fee), specify it here (in satoshi). This differs from fee in that this is an upper bound value, which fee is an exact value.
custom_inputs (list): Use only these specific UTXOs as inputs for the transaction being created. If specified, this parameter is a list of (JSON-encoded) UTXO objects (token), whose properties match those as retrieved by listunspent function from bitcoind (e.g. see here). Note that the actual UTXOs used may be a subset of this list.
unspent_tx_hash (string): When compiling the UTXOs to use as inputs for the transaction being created, only consider unspent outputs from this specific transaction hash. Defaults to null to consider all UTXOs for the address. Do not use this parameter if you are specifying custom_inputs.
regular_dust_size (integer): Specify (in satoshi) to override the (dust) amount of BTC used for each non-(bare) multisig output. Defaults to 5430 satoshi.
multisig_dust_size (integer): Specify (in satoshi) to override the (dust) amount of BTC used for each (bare) multisig output. Defaults to 7800 satoshi.
dust_return_pubkey (string): The dust return pubkey is used in multi-sig data outputs (as the only real pubkey) to make those the outputs spendable. By default, this pubkey is taken from the pubkey used in the first transaction input. However, it can be overridden here (and is required to be specified if a P2SH input is used and multisig is used as the data output encoding.) If specified, specify the public key (in hex format) where dust will be returned to so that it can be reclaimed. Only valid/useful when used with transactions that utilize multisig data encoding. Note that if this valis is set to false, this instructs counterparty-server to use the default dust return pubkey configured at the node level. If this default is not set at the node level, the call will generate an exception.
disable_utxo_locks (boolean): By default, UTXO’s utilized when creating a transaction are “locked” for a few seconds, to prevent a case where rapidly generating create_ calls reuse UTXOs due to their spent status not being updated in bitcoind yet. Specify true for this parameter to disable this behavior, and not temporarily lock UTXOs.
op_return_value (integer): The value (in satoshis) to use with any OP_RETURN outputs in the generated transaction. Defaults to 0. Don’t use this, unless you like throwing your money away.
With the exception of pubkey and allow_unconfirmed_inputs, these values should be left at their defaults, unless you know what you are doing.
Example code for creating a contract
In much the same way, we can place image hashes and even functional code in the Fort/Serpent/РАЯ style on the blockchain
DSSP - interactive structured programming system
The basic language of DSSP is the Developing Adaptive Language (RAYA)
(ДССП — диалоговая система структурированного программирования
Базовый язык ДССП — Развиваемый Адаптивный Язык (РАЯ) )
Brusentsov, the creator of the “Setun” ternary computer and language Developing Adaptive Language (RAYA), talked to me on the phone and talked about memristors in 2005.
def create_contract(self, code, endowment=0, sender=''):
if not sender:
sender = '82a978b3f5962a5b0957d9ee9eef472ee55b42f1' # PyEthereum uses ECDSA to derive this string from `sender = 0`.
util.credit(db, sender, config.XCP, max(endowment*2, 100000000), action='unit test', event='facefeed')
success, data = tester.state.do_send(self, sender, '', endowment, data=code)
contract_id = data
return contract_id
# Test serpent compilation of variables using _with_, doing a simple
# arithmetic calculation 20 * 30 + 10 = 610
sixten_code =\
'''
(with 'x 10
(with 'y 20
(with 'z 30
(seq
(set 'a (add (mul (get 'y) (get 'z)) (get 'x)))
(return (ref 'a) 32)
)
)
)
)
'''
def test_sixten():
s = tester.state()
c = s.contract('')
s.block.set_code(c, tester.serpent.compile_lll(sixten_code))
o1 = s.send(tester.k0, c, 0, [])
assert o1 == [610]
# Test Serpent's import mechanism
mul2_code = \
'''
return(msg.data[0]*2)
'''
filename = "mul2_qwertyuioplkjhgfdsa.se"
returnten_code = \
'''
x = create("%s")
return(call(x, 5))
''' % filename
def test_returnten():
s = tester.state()
open(filename, 'w').write(mul2_code)
c = s.contract(returnten_code)
o1 = s.send(tester.k0, c, 0, [])
os.remove(filename)
assert o1 == [10]
counterparty-lib provides a JSON RPC 2.0-based API based off of that of Bitcoin Core.
This type of memory is the most expensive - occupying a new cell in storage costs 20,000 gas- 26 cents. changing an occupied one costs 5,000, and reading costs 200. Why is it so expensive? The reason is simple - the data saved in the storage of the contract will be recorded in the blockchain and will remain there forever.
New bitcoin backend
Bitcore Node - https://github.com/bitpay/bitcore/tree/master/packages/bitcore-node
A standardized API to interact with multiple blockchain networks
Currently supporting: Bitcoin, Bitcoin Cash, Litecoin, Dogecoin, Ripple, Ethereum and Polygon
https://habr.com/ru/companies/domrf/articles/588737/
bitcore v10.0.28 with packages/crypto-wallet-core/package.json
"ethers": "^5.7.0" (Ethereum at list 5.7.0)
REST API Counterparty
Framework ethers instructions for use
const { ethers } = require('ethers')
const ContractArtifact = require('./SimpleMarketplace.json')
const CONTRACT_ADDRESS = ContractArtifact.networks['3'].address
Комментариев нет:
Отправить комментарий