iotaledger / wasp Goto Github PK

Node for IOTA Smart Contracts

License: Apache License 2.0

Go 68.74% Batchfile 0.04% Makefile 0.06% Rust 6.24% Dockerfile 0.06% Solidity 0.89% JavaScript 0.98% Smarty 0.01% CSS 0.03% HTML 0.02% Svelte 0.85% TypeScript 19.98% HCL 0.03% Shell 0.21% TLA 1.81% Assembly 0.05% Handlebars 0.01%

wasp's Issues

Chain (evm/evmlight) returns timeout for every write call

Branch: Develop
EVM Flavor: evmlight

Running a evm chain for several days the chain returned suddenly a timeout for every write call (via rpc). The chain was setuped with a block time which also paused and no block gets "minted" since the timeout error.

Example log from the RPC Interface for the timout response:

Nov 13 14:46:53 wasp-1-sazsjtfk wasprpc[410928]: REQUEST:  {"method":"eth_sendRawTransaction","params":["0xf8851380826906949a03bd40f5719353741f6e996dc12f93e4f88b7a80a4f3b837910000000000000000000000000000000000000000000000000000000000e4e1c0820456a070f5672731bd7a572a33a3b0ff35bab80cf33412998d8d7516aef33a3f14f6efa04058ee8a5a74bbe52f157378afc036b4bbd5531743f61226574787cb6744c3ae"],"id":49,"jsonrpc":"2.0"}
Nov 13 14:46:53 wasp-1-sazsjtfk wasprpc[410928]: RESPONSE: {"jsonrpc":"2.0","id":49,"error":{"code":-32000,"message":"GET http://10.1.0.183:9090/chain/tBDmLX2kBEXRCuE1yKrFsTYTwmB3ey5qQzPXMpQ4AVsV/request/2qej9Z3uDfjAraRPAvR5J7Ncn1TkgEtieWUK323LMy5g9EP/wait: 408: Timeout while waiting for request to be processed"}}

I checked the wasp logs but i cannout find any special error output. I also attached the logs.
wasp-logs.zip

All nodes have enough space left. Account which is running the RPC Interface has balance (IOTA: 2510)

AssemblyScript contract examples

Are there any plans to add more examples for other languages besides the main ones?

Unable to build schema tool

I am trying to build schema tool in master branch by using go language commands but I am getting
build github.com/iotaledger/wasp/tools/schema: cannot load io/fs: malformed module path "io/fs": missing dot in first path element error. I am using Ubuntu OS. Screen shot of the error and go language is version is attached as well. I have tried to build it from "tools" directory as well as from "wasp" directory.

Missing support for eip-1898 (e.g. for eth_call)

For several JSON-RPC methods (foremost eth_call) the eip-1898 should be supported.

Links:

For example currently any JSON RPC call eth_call with parameter { "blockHash": "0x...." } will result in the error: invalid argument 1: hex string without 0x prefix",

Call eth_getBlockByHash returns always null (evmlight)

Version: develop
EVM Flavor: evmlight

RPC call eth_getBlockByHash returns null for every block hash.

Example (by getting block by number first)

curl <RPC-URL> -X POST     -H "Content-Type: application/json"     -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params": ["latest",false],"id":1}'

# { ..."hash":"0x6a09626d31efb91d315723aa8bd81f50f0cf929393b76e25b5a2b835e601e58a", ...}

curl <RPC-URL> -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0x6a09626d31efb91d315723aa8bd81f50f0cf929393b76e25b5a2b835e601e58a", true],"id":60}'

# {"jsonrpc":"2.0","id":60,"result":null}

The same calls work on testnet (which standard evm flavor)

Wasp crashes after restarting (segfault)

Problem description

Running Wasp (develop 0.3.0) for the first time works fine, creating a chain, etc. But once I deploy a chain and close Wasp, then re-run it again it immediately panics:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x11173a1]

I can only run wasp again if I remove the database folder contents and start over but it's deterministically reproducable.

Proposed solution

Ideally wasp works more then 1 run and does not crash on the second time 😛

Malformed module

root@v278:/home/pea# cd /home/pea/wasp
root@v278:/home/pea/wasp# go build -tags rocksdb
build github.com/iotaledger/wasp: cannot load embed: malformed module path "embed": missing dot in first path element

eth_chainId request fails on current JSON-RPC (Metamask compatibility)

Metamask integration is currently not working because of a missing eth_chainId RPC method. By adding a network, Metamask is doing an explicit chainId request on the json-rpc method. This fails on the current RPC interface of WASP:

$ curl -X POST http://localhost:8545 -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":85}' -s
{"jsonrpc":"2.0","id":85,"error":{"code":-32601,"message":"the method eth_chainId does not exist/is not available"}}

Compare this on the Binance Smart Chain:

$ curl -X POST https://bsc-dataseed.binance.org --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":85}' -s
{"jsonrpc":"2.0","id":85,"result":"0x38"}

Which will give you the chainId in hex format.

Here is a snippet from Metamask doing the explicit call
(Source: https://github.com/MetaMask/metamask-extension/blob/604524f94d17df9b803b75e256eadacf20cac098/ui/pages/settings/networks-tab/network-form/network-form.component.js)

// ...
validateChainIdOnSubmit = async (formChainId, parsedChainId, rpcUrl) => {
    const { t } = this.context;
    let errorKey;
    let errorMessage;
    let endpointChainId;
    let providerError;

    try {
      endpointChainId = await jsonRpcRequest(rpcUrl, 'eth_chainId');
    } catch (err) {
      log.warn('Failed to fetch the chainId from the endpoint.', err);
      providerError = err;
    }
// ...

Here is also the EIP (in case of interest): https://eips.ethereum.org/EIPS/eip-695

Providing the eth_chainId would be the next step for making the next step regarding metamask compatibility.

wasp node failure with chain deploy: returns 404

Hello,
My wasp node is running in a docker and connects to a goshimmer in the same docker bridge network. (goshimmer node seems to be fully ok and running, except: found no faucet state of at least 1000....00000 Tokens)

Wasp node has no startup problems and api-connection is ok (---> Total 0 chain(s) in wasp node http://127.0.0.1:9090).

But if I try to deploy a chain with

./wasp-cli chain deploy --committee=0 --quorum=1 --chain=mychain --description="My chain"

the wasp logs this:

wasp     | 2021-11-07T08:57:52Z	INFO	webapi/adm	admapi/committeerecord.go:69	Committee record saved. Address: Committee(Address: aeA...eVC Nodes:[127.0.0.1:4000])
wasp     | 2021-11-07T08:57:52.629833827Z 172.18.0.1 POST /adm/committeerecord 201 error=""

which seems also ok, but the wasp-cli returns this:

creating new chain. Owner address: 1FnS...jXVe. State controller: ZP...jVR, N = 1, T = 1
creating chain origin and init transaction.. FAILED: CreateChainOrigin: unable to read error from response body: invalid character 'i' looking for beginning of value repsonseBody: internal server error, error: code=404, message=Not Found
error: DeployChain: CreateChainOrigin: unable to read error from response body: invalid character 'i' looking for beginning of value repsonseBody: internal server error, error: code=404, message=Not Found

Seems to be a 404 response but why and on which server? Strangely enough the local wallet Balance decreased (without creating a chain):
Address index 0
Address: 1Fn...5jXVe
Balance:
IOTA: 999000 (goes down every time I tried)
------
Total: 999000

my config.json (I think standard more or less)

{
  "database": {
    "directory": "waspdb"
  },
  "logger": {
    "level": "debug",
    "disableCaller": false,
    "disableStacktrace": true,
    "encoding": "console",
    "outputPaths": [
      "stdout",
      "wasp.log"
    ],
    "disableEvents": true
  },
  "network": {
    "bindAddress": "0.0.0.0",
    "externalAddress": "auto"
  },
  "node": {
    "disablePlugins": [],
    "enablePlugins": []
  },
  "webapi": {
    "bindAddress": "0.0.0.0:9090",
    "adminWhitelist": ["127.0.0.1", "172.18.0.1"]
  },
  "dashboard": {
    "auth": {
      "scheme": "basic",
      "username": "...",
      "password": "..."
    },
    "bindAddress": "0.0.0.0:7000"
  },
  "peering":{
    "port": 4000,
    "netid": "127.0.0.1:4000"
  },
  "nodeconn": {
    "address": "goshimmer:5000"
  },
  "nanomsg":{
    "port": 5550
  }
}

Missing support for eip-1898 (e.g. for eth_call) (Reopen)

Sorry, i have to reopen #486 again. I tested with revision 088d32a and still get some error.

The following call:

curl <rpc-url> -X POST -H 'Content-Type: application/json' -d ' {"jsonrpc":"2.0","method":"eth_call","params":[{"data":"0x95d89b41", "gas":"0x0", "to":"0x3edafd0258f75e0f49d570b1b28a1f7a042bcec3"},{"blockHash":"0x2a393342b6a9d91c2dc2446c678f7de2729da526922eed9c4a4656fee4fe7b14"}], "id": 768 }'

Results in

{"jsonrpc":"2.0","id":768,"error":{"code":-32000,"message":"GET http://127.0.0.1:9190/chain/gK4By51Z377RGVpRtX9e7tw2e7EQ3ZzTuagS3N65Ecp2/contract/adc164b5/callview/callContract: 400: View call failed: viewcontext: panic in VM: assertion failed: assertion failed:  EVMEmulator cannot access blocks other than the latest block"}}

The same call with parameter latest instead of the blockHash:

curl <rpc-url> -X POST -H 'Content-Type: application/json' -d ' {"jsonrpc":"2.0","method":"eth_call","params":[{"data":"0x95d89b41", "gas":"0x0", "to":"0x3edafd0258f75e0f49d570b1b28a1f7a042bcec3"},"latest"}], "id": 768 }'

Returns:

{"jsonrpc":"2.0","id":768,"result":"0x000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000045745544800000000000000000000000000000000000000000000000000000000"}

EVM: RPC endpoint issues

Encountered the following 2 EVM rpc implementation issues while writing a smart contract:

I had to explicitly set the gas limit (0 works) in my deploy tools to interact, since it was unable to request the gas from the node apparently; Maybe that function is not implemented?
I wrote a simple faucet smart contract and tried to deploy it - the deployment worked but while interacting with it I got a error while trying to call any function on it. It looks like it might be breaking in a hexify function or smth on the node side. I deployed it to the BSC testnet after that and there it worked as expected. I suspect the node is used for some argument conversion and is returning something that might not be what it is expecting:

Error:

(node:1406915) UnhandledPromiseRejectionWarning: Error: invalid hex string (argument="value", value="-0x0eef28", code=INVALID_ARGUMENT, version=bytes/5.4.0)
    at Logger.makeError (/home/dave/ethereum/faucet/node_modules/@ethersproject/providers/node_modules/@ethersproject/logger/src.ts/index.ts:225:28)
    at Logger.throwError (/home/dave/ethereum/faucet/node_modules/@ethersproject/providers/node_modules/@ethersproject/logger/src.ts/index.ts:237:20)

Deployed smart contract:

pragma solidity ^0.8.3;

/**
 * @title   Simple Faucet
 * @author  Dave de Fijter // IOTA Foundation
 */


contract SimpleFaucet {

    mapping (address => bool) private requestedAddresses;

    constructor() payable {
    }   

    receive() external payable {
    }   

    fallback() external payable {
    }   

    function getBalance() public view returns (uint) {
        // See how many native tokens are in the contract
        return address(this).balance;
    }   

    function requestFunds(address payable _to) public payable {
        // Request some funds to a provided address
        // Each address can only receive faucet tokens once
        require(10 ether >= address(this).balance, "Not enough funds in the faucet to send!");
        require(!requestedAddresses[_to], "This address already received some faucet tokens...");
        (bool sent, ) = _to.call{value: 10 ether}("");
        require(sent, "Failed to send tokens");
        requestedAddresses[_to] = true;
    }

}

Reproducable by deploying this contract and trying to call any function it, for example getBalance

Panic: processChainTransition. unexpected error: index 1 out of range for array of len 0

I get the following error after starting up a wasp-cluster (wasp-cluster start) for the latest develop version:

[ wasp 2] 2021-10-20T08:06:38Z  INFO    Chains.gK4By5.  committee/committee.go:234      committee started for address YxvQE98MPUa6BcW2UtSvmqkvr5nditSiwCe9t7PDtcXd
[!wasp 2] panic: processChainTransition. unexpected error: index 1 out of range for array of len 0
[!wasp 2]
[!wasp 2] goroutine 150 [running]:
[!wasp 2] go.uber.org/zap/zapcore.(*CheckedEntry).Write(0xc0000bc000, 0x0, 0x0, 0x0)
[!wasp 2]       /home/ubuntu/go/pkg/mod/go.uber.org/[email protected]/zapcore/entry.go:234 +0x58d
[!wasp 2] go.uber.org/zap.(*SugaredLogger).log(0xc00029b668, 0xc000290104, 0x2738f00, 0x2c, 0xc0005ef810, 0x1, 0x1, 0x0, 0x0, 0x0)
[!wasp 2]       /home/ubuntu/go/pkg/mod/go.uber.org/[email protected]/sugar.go:234 +0xf6
[!wasp 2] go.uber.org/zap.(*SugaredLogger).Panicf(...)
[!wasp 2]       /home/ubuntu/go/pkg/mod/go.uber.org/[email protected]/sugar.go:159
[!wasp 2] github.com/iotaledger/wasp/packages/chain/chainimpl.(*chainObj).processChainTransition(0xc000364180, 0xc0005a5020)
[!wasp 2]       /home/ubuntu/wasp/packages/chain/chainimpl/chainimpl.go:301 +0xa7b
[!wasp 2] github.com/iotaledger/wasp/packages/chain/chainimpl.NewChain.func2(0x2499c80, 0xc000362180, 0xc0001d7d10, 0x1, 0x1)
[!wasp 2]       /home/ubuntu/wasp/packages/chain/chainimpl/chainimpl.go:125 +0x62
[!wasp 2] github.com/iotaledger/hive.go/events.(*Event).Trigger.func2(0x24a1800, 0x3790540, 0x2499c80, 0xc000362180, 0x10)
[!wasp 2]       /home/ubuntu/go/pkg/mod/github.com/iotaledger/[email protected]/events/event.go:71 +0x5a
[!wasp 2] github.com/iotaledger/hive.go/datastructure/orderedmap.(*OrderedMap).ForEach(0xc000326c80, 0xc0005efa28, 0xc00024ca01)
[!wasp 2]       /home/ubuntu/go/pkg/mod/github.com/iotaledger/[email protected]/datastructure/orderedmap/orderedmap.go:119 +0x9b

Example config for node 2:

{                                                                                         
  "database": {                                                                           
    "inMemory": false,                                                                    
    "directory": "waspdb"                                                                 
  },                                                                                      
  "logger": {                                                                             
    "level": "debug",                                                                     
    "disableCaller": false,                                                               
    "disableStacktrace": true,                                                            
    "encoding": "console",                                                                
    "outputPaths": [                                                                      
      "stdout",                                                                           
      "wasp.log"                                                                          
    ],                                                                                    
    "disableEvents": true                                                                 
  },                                                                                      
  "network": {                                                                            
    "bindAddress": "0.0.0.0",                                                             
    "externalAddress": "auto"                                                             
  },                                                                                      
  "node": {                                                                               
    "disablePlugins": [],                                                                 
    "enablePlugins": []                                                                   
  },                                                                                      
  "webapi": {                                                                             
    "bindAddress": "0.0.0.0:9092"                                                         
  },                                                                                      
  "dashboard": {                                                                          
    "bindAddress": "0.0.0.0:7002"                                                         
  },                                                                                      
  "peering":{                                                                             
    "port": 4002,                                                                         
    "netid": "127.0.0.1:4002",                                                            
        "neighbors": ["127.0.0.1:4000","127.0.0.1:4001","127.0.0.1:4002","127.0.0.1:4003"]
  },                                                                                      
  "nodeconn": {                                                                           
    "address": "127.0.0.1:5000"                                                           
  },                                                                                      
  "nanomsg":{                                                                             
    "port": 5552                                                                          
  }                                                                                       
}

Tutorial not updated

I've tried to run through the tutorial and I have noticed some issues.
The examples in the tutorial is not updated:

I assume the ScExports::add_call has been renamed to add_func?
Chain.PostRequest is renamed to PostRequestSync

The tutorial example code works fine when run from it's own directory, but when I tried my own implementation I ran into problems with WasmLib::hostGetKeyId not being found. I included wasmlib using the git option in Cargo.toml.
When trying to go test on the TestTutorial3 with my own rust wasm:

=== RUN   TestTutorial3
53:56.779	INFO	TestTutorial3	solo/solo.go:166	deploying new chain 'ex3'
53:56.781	INFO	TestTutorial3.ex3	vmcontext/runreq.go:179	eventlog -> '[req] [0]APg5JhfUdiEDAgPuZbf8NdGhVLn2AB4TqSFKuwaRCUQ8: Ok'
53:56.782	INFO	TestTutorial3.ex3	solo/run.go:97	state transition #0 --> #1. Requests in the block: 1. Posted: 0
53:56.782	INFO	TestTutorial3	solo/clock.go:44	ClockStep: logical clock advanced by 1ms
53:56.782	INFO	TestTutorial3.ex3	solo/solo.go:245	chain 'ex3' deployed. Chain ID: bCsGV44yzmTgyV8xdM74TbJkvcb26o7nUjfufz9tSqnM
53:56.783	INFO	TestTutorial3.ex3	solo/req.go:211	callView: blob::getBlobInfo
53:56.786	INFO	TestTutorial3.registry.registry	registry/blobcache.go:43	data blob has been stored. size: 657437 bytes, hash: z28CLQktDhAf9yhHWbpqUpweksV6N9nLwgv5FXLT2RX
53:56.786	INFO	TestTutorial3	solo/solofun.go:92	Solo::PutBlobDataIntoRegistry: len = 657437, hash = z28CLQktDhAf9yhHWbpqUpweksV6N9nLwgv5FXLT2RX
53:56.786	INFO	TestTutorial3.ex3	solo/req.go:211	callView: root::getFeeInfo
53:56.787	INFO	TestTutorial3.ex3	solo/req.go:181	PostRequestSync: blob::storeBlob -- [0]6MPKavAm9tAW6mXvr8fPUb7Hv7xcaP7tE8fUiCFL57y7
53:56.788	INFO	TestTutorial3.ex3	vmcontext/log.go:4	eventlog::fd91bc63 -> '[blob] hash: GniwweDrKLWxkmBTsZzXsmHrQq2We1m8qQHK2nQ9M2HV, field sizes: [657437 10]'
53:56.788	INFO	TestTutorial3.ex3	vm/event.go:24	bCsGV44yzmTgyV8xdM74TbJkvcb26o7nUjfufz9tSqnM::fd91bc63/event [blob] hash: GniwweDrKLWxkmBTsZzXsmHrQq2We1m8qQHK2nQ9M2HV, field sizes: [657437 10]
53:56.788	INFO	TestTutorial3.ex3	vmcontext/runreq.go:179	eventlog -> '[req] [0]6MPKavAm9tAW6mXvr8fPUb7Hv7xcaP7tE8fUiCFL57y7: Ok'
53:56.800	INFO	TestTutorial3.ex3	solo/run.go:97	state transition #1 --> #2. Requests in the block: 1. Posted: 0
53:56.800	INFO	TestTutorial3	solo/clock.go:44	ClockStep: logical clock advanced by 1ms
53:56.801	INFO	TestTutorial3.ex3	solo/req.go:181	PostRequestSync: root::deployContract -- [0]9PjyzcETE8uLn1qnkmx4RV9uezhS2fHtgdwF75puXQJR
53:57.486	PANIC	TestTutorial3.ex3	vmcontext/log.go:12	root.deployContract.fail: unknown import: `WasmLib::hostGetKeyId` has not been defined
53:57.486	ERROR	TestTutorial3.ex3	vmcontext/runreq.go:172	recovered from panic in VM: root.deployContract.fail: unknown import: `WasmLib::hostGetKeyId` has not been defined
53:57.486	INFO	TestTutorial3.ex3	vmcontext/runreq.go:179	eventlog -> '[req] [0]9PjyzcETE8uLn1qnkmx4RV9uezhS2fHtgdwF75puXQJR: recovered from panic in VM: root.deployContract.fail: unknown import: `WasmLib::hostGetKeyId` has not been defined'
53:57.487	INFO	TestTutorial3.ex3	solo/run.go:97	state transition #2 --> #3. Requests in the block: 1. Posted: 0
53:57.487	INFO	TestTutorial3	solo/clock.go:44	ClockStep: logical clock advanced by 1ms
    contract_test.go:17: 
        	Error Trace:	contract_test.go:17
        	Error:      	Received unexpected error:
        	           	recovered from panic in VM: root.deployContract.fail: unknown import: `WasmLib::hostGetKeyId` has not been defined
        	Test:       	TestTutorial3
--- FAIL: TestTutorial3 (0.71s)

Any idea why this happens?

Why are you assigning a UInt8Array variable to a "number" property?

wasp/contracts/wasm/fairroulette/frontend/src/lib/wasp_client/binary_models/off_ledger.ts

Line 29 in 5b5d294

args.push({ key: key, value: value });

In the end of the function, "args" is assigned to "IOffledger.arguments, which is OffLedgerArgument[]. That means every arg.value must be "number".

Also, the key must be a string, instead of UInt8Array

Flaky lpp tests

lpp tests sometimes hang (on latest develop)

I can reproduce consistently with the following command:

 go test -timeout 200s github.com/iotaledger/wasp/packages/peering/lpp -count 100 -failfast

1 test takes ~0.139s to run on my machine, so 100 tests should be around 14s, however the 200s above are not enough and it times out.

This happened to me the first time randomly when running make test

Deploying to evm fails with invalid memory address

Branch: Develop

Deploying a Smart Contract to EVM Chain fails with the following error:

GET http://127.0.0.1:9090/chain/mbzESjyjzkzbLEcs1JeXKYzT4gpNLA41NQqbkxSBq2Rj/contract/adc164b5/callview/getBlockByNumber: 400: View call failed: viewcontext: panic in VM: runtime error: invalid memory address or nil pointer dereference

Command request-funds of wwallet does not work

Error in request-funds command

wasp-cli.exe set utxodb true
wasp-cli.exe init
Initialized wallet seed in wasp-cli.json
wasp-cli.exe request-funds
error: invalid character '<' looking for beginning of value

When i use request-funds command, i get this error:

error: invalid character '<' looking for beginning of value

WASP communication with public IPs

I try to setup a wasp communitee with different wasp members (not in the same local network)

In our working setup we have servers with internal/external IP adresses. When we have the communication between the nodes on an the internal network (10.x.x.x), there I can create the peering trust and new chains, all works fine. When I try to setup the trust on this nodes with there external IP adresses, I got a an error (500 error="cannot create peer network config provider") on chain deploy. The peering is listed as up but the chain ID is there with error message. code=404, message=Chain not found. Any sugestions whats wrong?

type *client.GoShimmerAPI has no field or method GetTransactionInclusionState

Hello, if i try this example

package main

import (
	"fmt"

	"github.com/iotaledger/wasp/client/goshimmer"
)

func main() {

	goshimmerclient := "https://api.goshimmer.sc.iota.org"
	goshimmerclient_API := goshimmer.NewClient(goshimmerclient, -1)
	fmt.Println(goshimmerclient_API)

}

i get this error

 github.com/iotaledger/wasp/client/goshimmer
..\..\..\..\go\pkg\mod\github.com\iotaledger\[email protected]\client\goshimmer\goshimmer.go:107:22: c.api.GetTransactionInclusionState undefined (type *client.GoShimmerAPI has no field or method GetTransactionInclusionState)

cannot find -lwasmtime

ubuntu@ubuntu:~/wasp$ go run main.go
github.com/bytecodealliance/wasmtime-go
/usr/bin/ld: cannot find -lwasmtime
collect2: error: ld returned 1 exit status

the wasmtimevm could not be retrieved on wasmtime branch
Ubuntu 20.04.1 LTS

Goshimmer node crashes creating new chain on refactor branch

Error from wasp-cli

goshimmer node

Any hint? Thanks !

RPC call eth_getBlockByNumber ignores "earliest"

The RPC call eth_getBlockByNumber ignores the block parameter "earliest" in the current wasp version (develop). Instead it will give you the same result as latest and not the genesis block.

According to https://eth.wiki/json-rpc/API#the-default-block-parameter the options are:

HEX String - an integer block number

String "earliest" for the earliest/genesis block

String "latest" - for the latest mined block

String "pending" - for the pending state/transactions

Example call with parameter latest

curl http://localhost:8545 \
-X POST \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params": ["latest",false],"id":1}'

Example with parameter earliest

curl http://localhost:8545 \
-X POST \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params": ["earliest",false],"id":1}'

Both with return something like:

{"jsonrpc":"2.0",
"id":1,
"result":{"difficulty":
"0x20000","extraData":"0x",
"gasLimit":"0xe4e1c0",
"gasUsed":"0x6685",
"hash":"0xa3c26d7e5337326dd5fa1df464b0ebfb6d34b8903d3a0b6f9ae15c14d91b9093","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","miner":"0x0000000000000000000000000000000000000000","mixHash":"0x0000000000000000000000000000000000000000000000000000000000000000","nonce":"0x0000000000000000",
"number":"0xb6",
"parentHash":"0xd240fb37442fd59306af9ab082294f1b4d1bf8074be7488a686d866824507a09",
"receiptsRoot":"0xfb06eff35a1555f20fbdee179671e9ce95ece459f6ae38453708b591b06a4f99","sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347","size":"0x26b","stateRoot":"0x865bac87431b8f9bf80367755658130febc2b02508e28979fa030bc9b90b9218","timestamp":"0x61601132","transactions":["0x399d3cfa0e0cb375b51d34164a64c4c3a7d426bd3e039d5cd8b1c484ebaa4ae3"],"transactionsRoot":"0x922c67361ea40f5b10277a198b56693b431938f7b135d380297c7d89b9b4b630","uncles":[]}}

UPDATE:
It seesms that the eth_getBlockByNumber also ignores a given hex string and always returns the current block (latest)

Happy to contribute

Hi There, I will be happy to contribute. Please advice

Wrong link for snapshot

At https://github.com/iotaledger/wasp/blob/master/docs/docs/runwasp.md
on step 2
curl 'https://github.com/iotaledger/goshimmer/raw/master%2Bwasp/snapshot.bin' -O
gives an error because it's a redirect link
the correct command should be
curl 'https://raw.githubusercontent.com/iotaledger/goshimmer/master%2Bwasp/snapshot.bin' -O

Illegal instruction error when starting wasp

Just followed the install guide:

git clone https://github.com/iotaledger/wasp
cd wasp
make install
./wasp
./wasp-cli

Installed the dependencies - rocksdb and goshimmer.

sudo pacman -S rocksdb go
Packages (1) rocksdb-6.23.3-1
go version go1.17.1 linux/amd64

Compiled and running on same laptop. CPU:

    CPU family:          6
    Model:               42
    Thread(s) per core:  2
    Core(s) per socket:  2
    Socket(s):           1
    Stepping:            7
    CPU max MHz:         3200.0000
    CPU min MHz:         800.0000
    BogoMIPS:            4988.20
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx rdtscp lm con
                         stant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse
                         3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexp
                         riority ept vpid xsaveopt dtherm ida arat pln pts md_clear flush_l1d

Attaching GDB trace:

shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.

0x00000000021019ef in rocksdb::LRUCache::LRUCache(unsigned long, int, bool, double, std::shared_ptr<rocksdb::MemoryAllocator>, bool, rocksdb::CacheMetadataChargePolicy) ()
(gdb)

waspconn.PLUGINS 0.2.4 not runable as plugins.WaspConn 0.3.0

How to configure waspcon Plugin from https://github.com/iotaledger/goshimmer/tree/wasp wasp branch to work with 0.3.*?

Wiki Faucet plugin - no seed

https://wiki.iota.org/wasp/guide/chains_and_nodes/running-a-node#enable-txstream-and-faucet-plugins

Enabling faucet plugin gives me the following error upon running my goshimmer node

Faucet node/plugin.go:86 a seed must be defined when enabling the faucet plugin

Instructions to be added to the page.

Interact with core contracts

How it's possible to interact with core contracts https://wiki.iota.org/smart-contracts/guide/core_concepts/core_contracts/overview of wasp node for example gov-contract https://wiki.iota.org/smart-contracts/guide/core_concepts/core_contracts/governance? There are no exapmle about that

dwf not incrementing amount correctly

is anyone successfully running wasp-cli donatewithfeedback SC with runtime amount and/or feedback key/values?
and confirmed those values are indeed used by SC?

below are my steps in attempting the same. it assumes goshimmer (with waspconn) is already installed on your system.

SC seems to run, but i'm specifically not seeing donation amount/feedback used or shown anywhere in the dwf dashboard. what's further concerning is no logs from any of the attempted SC source files appear in stdout, which further tells me none of the SC's attempted are actually executed.

hoping someone can follow the steps and point out if/where i'm missing something:

// install wasp executables
$ cd <wasp_root_dir>
$ go install ./... // should install wasp, wasp-cli, wasp-cluster

// start cluster
$ wasp-cluster init my-cluster // should create "my-cluster" directory with necessary files in it
$ cd my-cluster/
$ wasp-cluster start

// initialize wallet, set utxo, confirm address and balance
$ mkdir <some_dir> && cd <some_dir>
$ wasp-cli init
$ wasp-cli set utxodb true
$ cat wasp-cli.json // should show utxo true

// add funds to balance
$ wasp-cli balance // should show nothing
$ wasp-cli address
$ wasp-cli request-funds
$ wasp-cli balance // should so a non-zero balance

// deploy chain
$ wasp-cli chain deploy --chain=<chain_name> --description="chain description"
// open localhost:7000 in webbrowser, above created chain should be visible

// deploy contract (3 variations below, each attempted unsuccessfully)
$ wasp-cli chain deploy-contract examplevm <chain_name> "chain description" <wasp_root_dir>/contracts/rust/donatewithfeedback/wasmmain/donatewithfeedback.go
or
$ wasp-cli chain deploy-contract examplevm <chain_name> "chain description" <wasp_root_dir>/contracts/rust/donatewithfeedback/src/donatewithfeedback.rs
or
$ wasp-cli chain deploy-contract examplevm <chain_name> "chain description" <wasp_root_dir>/contracts/rust/donatewithfeedback/donatewithfeedback.go
(note: examplevm in each above was also attempted replaced with wasmtimevm, but still no success)

// call donate with amount "2"
$ wasp-cli chain post-request <chain_name> donate string amount string 2
// open localhost:7000 in webbrowser, balance has NOT increased by 2 as expected- only 1

Websockets seem to halt the execution of smart contracts

Unfortunately I can't offer an extensive log, but just speak out of the experience I made throughout the testing.

The execution of the current fairroulette contract emits a few events which are sent via Nanomsg. Our current Websocket implementation listens to these events and publishes them through a Websocket port.

Somewhere in these stages, (this could also mean that the Nanomsg itself is the reason), Wasp behaves very uncoorperative. For example: Messages being dropped, whole execution halts at any random moment, the WS connection suddenly dies. Sometimes this is unrecoverable and requires the deletion of the Waspdb. Once I got this error message after restarting wasp storeSyncingData not needed: stateOutput is nil

I have experienced that, as soon as I drop off the Websocket connection and restart Wasp, the execution works reliable again.

Method handler crashes on eth_getTransactionReceipt call with unkown hash

Current branch/commit: develop@92af65f7677d4fbb15763c62edf1d08be35d37a7

Steps

Start disposable cluster wasp-cluster start -d
Create chain/committee, deploy evm chain and start rpc gateway
Send eth_getTransactionReceipt with unkown hash:

    const fs = require('fs');
    const SIGNING_KEY = fs.readFileSync(".secret2").toString().trim();

    const provider = new ethers.providers.JsonRpcProvider(MY_WASP_RPC);
    const signer = new Wallet(SIGNING_KEY, provider);

    const txHash = '0xd810471d1710df724314757afeb9533786d55bfe5e9df1a8584c154e5e91187f';

    console.log(await provider.getTransactionReceipt(txHash)); //should output null

This will throw an error:
Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":44,\"error\":{\"code\":-32000,\"message\":\"method handler crashed\"}}\n", error={"code":-32000}, requestBody="{\"method\":\"eth_getTransactionReceipt\",\"params\":[\"0xd810471d1710df724314757afeb9533786d55bfe5e9df1a8584c154e5e91187f\"],\"id\":44,\"jsonrpc\":\"2.0\"}", requestMethod="POST", url="SOME_URL", code=SERVER_ERROR, version=web/5.4.0

Expected Behavior:
According to the alchemy docs (https://docs.alchemy.com/alchemy/documentation/apis/ethereum#eth_gettransactionreceipt) the eth_transactionReceipt call shoud return null on unkown tx hashes.

I tested this also on a local ganache environment and the same code will return null

Apple M1 Support

wasp uses wasmtime go library which doesn't work on M1 right now.

Running go install shows:

# github.com/bytecodealliance/wasmtime-go
ld: library not found for -lwasmtime

Once wasmtime-go supports M1, which in turn is stuck on Github CI support, wasp should work as well.

Alternatively, if anyone has any idea around making it work without github ci support, would be great.

cluster with more than one wasp-node in a chain

Input:
./wasp-cli chain deploy --chain=1337chain --committee='0,1' --quorum=2 --description="My1337chain"

output

creating new chain. Owner address: 1BEEo7HtgdpDHfKqMfSWHzikcpLJEXGYc5dgZUUhPygUc. State controller: NsgmyCq9MW1WYSQyMbnC7Q5tG6bbqNEYtg24dUUt25DA, N = 2, T = 2
creating chain origin and init transaction.. OK
sending committee record to nodes.. OK
activating chain grRpwxTKA7Lp92FrQkPK4SncikSBddmgpKKGjVZnwKb9.. OK.
waiting root init request transaction.. FAILED: #0: GET http://127.0.0.1:9090/chain/grRpwxTKA7Lp92FrQkPK4SncikSBddmgpKKGjVZnwKb9/request/5sPE84iXjqs5nzVrhHMjpsfjfMrXtD4wrBNpRvqMLeGSBbm/wait: Get "http://127.0.0.1:9090/chain/grRpwxTKA7Lp92FrQkPK4SncikSBddmgpKKGjVZnwKb9/request/5sPE84iXjqs5nzVrhHMjpsfjfMrXtD4wrBNpRvqMLeGSBbm/wait": dial tcp 127.0.0.1:9090: connectex: No connection could be made because the target machine actively refused 
it.
#1: GET http://127.0.0.1:9091/chain/grRpwxTKA7Lp92FrQkPK4SncikSBddmgpKKGjVZnwKb9/request/5sPE84iXjqs5nzVrhHMjpsfjfMrXtD4wrBNpRvqMLeGSBbm/wait: Get "http://127.0.0.1:9091/chain/grRpwxTKA7Lp92FrQkPK4SncikSBddmgpKKGjVZnwKb9/request/5sPE84iXjqs5nzVrhHMjpsfjfMrXtD4wrBNpRvqMLeGSBbm/wait": dial tcp 127.0.0.1:9091: connectex: No connection could be made because the target machine actively refused it.

error: DeployChain: #0: GET http://127.0.0.1:9090/chain/grRpwxTKA7Lp92FrQkPK4SncikSBddmgpKKGjVZnwKb9/request/5sPE84iXjqs5nzVrhHMjpsfjfMrXtD4wrBNpRvqMLeGSBbm/wait: Get "http://127.0.0.1:9090/chain/grRpwxTKA7Lp92FrQkPK4SncikSBddmgpKKGjVZnwKb9/request/5sPE84iXjqs5nzVrhHMjpsfjfMrXtD4wrBNpRvqMLeGSBbm/wait": dial tcp 127.0.0.1:9090: connectex: No connection could be made because the target machine actively refused it.
#1: GET http://127.0.0.1:9091/chain/grRpwxTKA7Lp92FrQkPK4SncikSBddmgpKKGjVZnwKb9/request/5sPE84iXjqs5nzVrhHMjpsfjfMrXtD4wrBNpRvqMLeGSBbm/wait: Get "http://127.0.0.1:9091/chain/grRpwxTKA7Lp92FrQkPK4SncikSBddmgpKKGjVZnwKb9/request/5sPE84iXjqs5nzVrhHMjpsfjfMrXtD4wrBNpRvqMLeGSBbm/wait": dial tcp 127.0.0.1:9091: connectex: No connection could be made because the target machine actively refused it.

what goes wrong?

wasp-cluster init panics

Branch: develop (commit: af05fed)

Steps to reproduce:

go install ./...
cd $HOME
wasp-cluster init my-cluster

Expected:
Initialized cluster

Actual:
wasp-cluster ends with a panic "pow" shorthand is more than one ASCII characterpanic: "pow" shorthand is more than one ASCII character

Wasp evm/rpc accepts duplicate transaction nonce

Current branch/commit: develop@92af65f7677d4fbb15763c62edf1d08be35d37a7

Steps To reproduce:

started wasp cluster with inMemory: true configuration
get the latest nonce with await provider.getTransactionCount(from, "latest"); e.g. 2
send transaction (e.g. ether.js)

    const provider = new ethers.providers.JsonRpcProvider();
    const signer = new Wallet(SIGNING_KEY, provider);

    const gas_limit = 30000;
    const nonce = 2
    console.log(`Nonce: ${nonce}`);
    const tx = {
        from,
        to,
        value: ethers.utils.parseEther(amount_in_eth),
        nonce,
        gasLimit: ethers.utils.hexlify(gas_limit), // 100000   
        gasPrice: provider.getGasPrice(),  
      }

    const tx1 = await signer.sendTransaction(tx);
    const receipt = await tx1.wait();

You can send the transaction over and over again.

I tried to reproduce this with ganache and it will result in:
Error: processing response error (body="{\"id\":52,\"jsonrpc\":\"2.0\",\"error\":{\"message\":\"the tx doesn't have the correct nonce. account has nonce of...

Error in packages/vm/core/accounts/impl.go

The following line is using the wrong parameter. It should use ParamAmount instead of ParamAgentID.

wasp/packages/vm/core/accounts/impl.go

Line 162 in 411ccd1

amount, ok, err := codec.DecodeInt64(ctx.Params().MustGet(ParamAgentID))

Calling smart contract view functions via API causes panics when done in parallel

I'm using the current fairroulette contract as an example.

To call a view function I'm using this URL:

http://127.0.0.1:9090/chain/dTneb78gLtGVj4PiHQNPwUXXbkpqaxzMFmFCV3ZtwMcL/contract/df79d138/callview/roundNumber [GET]

This should return a 200, with the following result:

{"Items":[{"Key":"cm91bmROdW1iZXI=","Value":"AAAAAAAAAAA="}]}

If you request multiple view functions by doing sequential calls:

curl http://127.0.0.1:9090/chain/dTneb78gLtGVj4PiHQNPwUXXbkpqaxzMFmFCV3ZtwMcL/contract/df79d138/callview/roundNumber
curl http://127.0.0.1:9090/chain/dTneb78gLtGVj4PiHQNPwUXXbkpqaxzMFmFCV3ZtwMcL/contract/df79d138/callview/roundStatus
curl http://127.0.0.1:9090/chain/dTneb78gLtGVj4PiHQNPwUXXbkpqaxzMFmFCV3ZtwMcL/contract/df79d138/callview/fooBar

This works without issues.

Running them in parallel by using '&' at the end of the curl requests, seems to mix the responses in some way.
Sometimes the first response throws a 400 Bad Request, while the second request is a 200 OK but contains the data of response 1+2 like this:

{"Items":[{"Key":"cm91bmROdW1iZXI=","Value":"AAAAAAAAAAA="}, {"Key":"cm91bmRTdGF0dXM=","Value":"AAAAAAAAAAA="}]}

It appears to me that the execution is currently not thread safe.

Further logging:

2021-09-08T12:07:00.732479952+02:00 127.0.0.1 GET /chain/pTwrRdxREzM12sMoSKaNirdnFWPrMjpiku8zFdTzniLr/contract/df79d138/callview/roundStatus 400 error="View call failed: go panicked"
2021-09-08T12:07:00.732576474+02:00 127.0.0.1 GET /chain/pTwrRdxREzM12sMoSKaNirdnFWPrMjpiku8zFdTzniLr/contract/df79d138/callview/roundNumber 400 error="View call failed: viewcontext: panic in VM: null.invalid key: 6"
2021-09-08T12:07:00.732655763+02:00 127.0.0.1 GET /chain/pTwrRdxREzM12sMoSKaNirdnFWPrMjpiku8zFdTzniLr/contract/df79d138/callview/roundStartedAt 400 error="View call failed: wasm trap: call stack exhausted\nwasm backtrace:\n  0: 0xffffffff - \u003cunknown\u003e!\u003cwasm function 144\u003e\n  1: 0x71ac - \u003cunknown\u003e!\u003cwasm function 91\u003e\n  2: 0x6642 - \u003cunknown\u003e!\u003cwasm function 64\u003e\n  3: 0x6f64 - \u003cunknown\u003e!\u003cwasm function 85\u003e\n  4: 0x786b - \u003cunknown\u003e!\u003cwasm function 116\u003e\n  5: 0x58b5 - \u003cunknown\u003e!\u003cwasm function 44\u003e\n"
2021-09-08T12:07:00.73293551+02:00 127.0.0.1 GET /chain/pTwrRdxREzM12sMoSKaNirdnFWPrMjpiku8zFdTzniLr/contract/df79d138/callview/lastWinningNumber 400 error="View call failed: wasm trap: call stack exhausted\nwasm backtrace:\n  0: 0xffffffff - \u003cunknown\u003e!\u003cwasm function 144\u003e\n  1: 0x71ac - \u003cunknown\u003e!\u003cwasm function 91\u003e\n  2: 0x6642 - \u003cunknown\u003e!\u003cwasm function 64\u003e\n  3: 0x6e31 - \u003cunknown\u003e!\u003cwasm function 82\u003e\n  4: 0x77f5 - \u003cunknown\u003e!\u003cwasm function 114\u003e\n  5: 0x58b5 - \u003cunknown\u003e!\u003cwasm function 44\u003e\n"

JSON/RPC balance reporting for native gas asset

Problem description

Metamask and potentially other tooling expect the base token to have 18 decimals by default like Ethereum has. MIOTA/Shimmer only has 6 decimals. This means that if I send 1Mi to my L2 account it still shows up rounded down as 0 in MetaMask, given 1 base unit would be 1e18 iota (1000Pi, where the total supply of IOTA is 2.7Pi). MetaMask does not support custom decimals for the base currency, making the balance display pretty much useless per default. Also the Gas Price field in sending transactions is hardcoded to GWEI (1e9*lowest unit), it's rather unclear as to what this field would represent.

Possible solutions

There is no perfect solution for this without custom decimal support in MetaMask, so I see 2 possible solutions:

We do a PR to MetaMask to support this setting
- Unclear path
- Might take a lot of time before it gets approved, and no guarantees it will at all
- Unknown how much needs to change in Metamask to accommodate this
Multiply the balance by 1e12 (or 1e18 - DECIMALS where DECIMALS is a new setting optionally occupied with the decimals setting from the info endpoint from Hornet if the same base currency is used.
- Easy to implement (1-line addition in packages/evm/jsonrpc/evmchain.go in the Balance function)
- Hacky, just for reporting balance now, with potential additional functionality like sending base tokens later on if supported at all this needs to be taken into account
- Given we give more padding to our lowest possible unit any modification using this would need to check we don't pass more precision as needed
- Potentially unexpected behavior for other tooling

I tested 2 and it correctly reports in MetaMask now, but it feels a bit wrong to do it like this. Let's discuss the potential solutions and alternatives here given this might be quite important for the user experience to get right.

wasp-cluster commands more than one ASCII character

wasp-cluster start ends with an error:

"gp" shorthand is more than one ASCII characterpanic: "gp" shorthand is more than one ASCII character

goroutine 1 [running]:
github.com/spf13/pflag.(*FlagSet).AddFlag(0xc00018c400, 0xc0001dc280)
        /home/ubuntu/go/pkg/mod/github.com/spf13/[email protected]/flag.go:864 +0x765
github.com/spf13/pflag.(*FlagSet).VarPF(0xc00018c400, 0xd17a30, 0xc0001b6c78, 0xc3a8d1, 0x10, 0xc34038, 0x2, 0xc39665, 0xe, 0xc0001dc1e0)
        /home/ubuntu/go/pkg/mod/github.com/spf13/[email protected]/flag.go:831 +0x10b
github.com/spf13/pflag.(*FlagSet).VarP(...)
        /home/ubuntu/go/pkg/mod/github.com/spf13/[email protected]/flag.go:837
github.com/spf13/pflag.(*FlagSet).IntVarP(0xc00018c400, 0xc0001b6c78, 0xc3a8d1, 0x10, 0xc34038, 0x2, 0x1388, 0xc39665, 0xe)
        /home/ubuntu/go/pkg/mod/github.com/spf13/[email protected]/int.go:46 +0x98
main.main()
        /home/ubuntu/wasp/tools/cluster/wasp-cluster/main.go:41 +0x518

Command request-funds does not work

Hello,

The option request-funds for the command wwallet does not work. When I run it, the node has not any currency balance.

Regards

Luciano Augusto Campagnoli da Silva

Race condition in mempool on inBufCounter and outBufCounter

Golang's race condition detector detects a race condition in mempool (packages/chain/mempool/mempool.go) about inBufCounter of Mempool structure. It notes that write in line 81 of the code:

72	func (m *Mempool) addToInBuffer(req iscp.Request) bool {
73		// just check if it is already in the pool
74		if m.HasRequest(req.ID()) {
75			return false
76		}
77		m.inMutex.Lock()
78		defer m.inMutex.Unlock()
79		// may be repeating but does not matter
80		m.inBuffer[req.ID()] = req
81		m.inBufCounter++
82		return true
83	}

may have a race with read at line 418:

411	func (m *Mempool) Info() chain.MempoolInfo {
412		m.poolMutex.RLock()
413		defer m.poolMutex.RUnlock()
414
415		ret := chain.MempoolInfo{
416			InPoolCounter:  m.inPoolCounter,
417			OutPoolCounter: m.outPoolCounter,
418			InBufCounter:   m.inBufCounter,
419			OutBufCounter:  m.outBufCounter,
420			TotalPool:      len(m.pool),
421		}
...
429		return ret
430	}

What is the best way to fix this. atomic object instead of int? Or maybe some other approach? I see there is a inMutex object. Maybe read must be locked via it too?

Similar message is obtained for outBufCounter variable. Write happens in line 419, read occurs in line 90:

85	func (m *Mempool) removeFromInBuffer(req iscp.Request) {
86		m.inMutex.Lock()
87		defer m.inMutex.Unlock()
88		if _, ok := m.inBuffer[req.ID()]; ok {
89			delete(m.inBuffer, req.ID())
90			m.outBufCounter++
91		}
92	}

wasp-cluster request-funds fails

hello, all. is anyone successfully getting wasp-cluster to service call

wasp-cli request-funds

my attempts all yield result

using Goshimmer host 127.0.0.1:8080
error: Faucet request seems to have failed

i'm using steps defined in wasp-cluster steps wiiki

note: as seen below, 40 minutes transpired and wasp-cluster still did not sync, however i suspect since intended for standalone testing, synching may not be relevant in this context.

[cluster] started 4 Wasp nodes

       The cluster started

[wasp-cluster] Press CTRL-C to stop
[ wasp 3] 2021-01-19T17:52:41-05:00 INFO Dashboard dashboard/plugin.go:49 Starting Dashboard ...
[ wasp 3] 2021-01-19T17:52:41-05:00 INFO Node node/node.go:117 Starting Plugin: Dashboard ... done
[ wasp 3] 2021-01-19T17:52:41-05:00 INFO Node node/node.go:117 Starting Plugin: wasmtimevm ... done
[ wasp 3] 2021-01-19T17:52:41-05:00 INFO Node node/node.go:117 Starting Plugin: Globals ... done
[ wasp 3] 2021-01-19T17:52:41-05:00 INFO Node node/node.go:120 Starting background workers ...
[ wasp 3] 2021-01-19T17:52:41-05:00 INFO Dispatcher dispatcher/plugin.go:72 dispatcher started
[ wasp 3] 2021-01-19T17:52:41-05:00 INFO Dashboard dashboard/plugin.go:60 Dashboard started, bind address=0.0.0.0:7003
[ wasp 3] 2021-01-19T17:52:41-05:00 INFO WebAPI webapi/plugin.go:103 WebAPI started, bind-address=0.0.0.0:9093
[ wasp 3] 2021-01-19T17:52:41-05:00 INFO NodeConn nodeconn/waspconn.go:34 connecting with node at 127.0.0.1:5000
[ goshimmer] 2021-01-19T17:52:41-05:00 INFO WaspConn.127.0.0.1:4003 connector/connector.go:81 wasp connection id has been set to '127.0.0.1:4003' for '127.0.0.1:51484'
[ goshimmer] 2021-01-19T17:52:44-05:00 INFO Clock clock/plugin.go:98 Synchronizing clock... done

^C[ wasp 1] 2021-01-19T18:38:27-05:00 WARN Graceful Shutdown gracefulshutdown/plugin.go:39 Received shutdown request - waiting (max 60) to finish processing ...

Docs - Stardust Updates

Description

With the upcoming changes, some articles in the documentation may require updates and versioning.

Motivation

We need to be able to launch products with their respective docs to improve the overall developer experience.

Requirements

The following pages may require updating. Please feel free to add or remove any items you see fit.

ISCP architecture
On-ledger requests may need some tweaking
Running a node
Using Docker
Configuring wasp-cli
Setting up a chain
testnet
Wasm VM section
Dev tools
Example Projects

Are you planning to do it yourself in a pull request?

To what extent I can, but the @iotaledger/tech-writers team will require support from the developers to know exactly what should be updated.

Missleading error on wrong gaslimit

Steps:

Running wasp-cluster with option inMemory : true on all nodes
Sending as tx with ether.js with following options:

    const provider = new ethers.providers.JsonRpcProvider(url);
    const signer = new Wallet(SIGNING_KEY, provider);

    const gas_limit = 10000;
    const tx = {
        from,
        to,
        value: ethers.utils.parseEther(amount_in_eth),
        nonce: provider.getTransactionCount(from, "latest"),
        gasLimit: ethers.utils.hexlify(gas_limit), 
        gasPrice: provider.getGasPrice(),  
      }

    const tx1 = await signer.sendTransaction(tx);
    const receipt = await tx1.wait();

Running the command gives the following error UnhandledPromiseRejectionWarning: Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":55,\"error\":{\"code\":-32000,\"message\":\"method handler crashed\"}}\n", error={"code":-32000}, requestBody="{\"method\":\"eth_getTransactionReceipt\",\"params\":[\"0x388d7dbe3a0aad0bec95e1aa60838f458a9dc392af527da4831171ade8fcc6d5\"],\"id\":55,\"jsonrpc\":\"2.0\"}", requestMethod="POST", url="<MY WONDERFUL WASP URL>", code=SERVER_ERROR, version=web/5.4.0)
In the logs it gives me an error regarding wrong gaslimit DEBUG Chains.izcbUY..c runvm/runtask.go:79 runTask, ERROR running request: M7exjP9mH7f6FavXjEe1eX7pNPBsVKjPx4TpPXTfo4C199, error: panic in VM: assertion failed: assertion failed: intrinsic gas too low: have 10000, want 21000

Make keepAmount for evmlight configurable

Currently the "evmlight" flavor keeps only n blocks in the database. The flag keepAmount is currently hardcoded to 100 blocks. For various scenarios this amount is too small (e.g. subgraphs).

A proposal would be to make this configurable on contract deployment.

Examples:

For specific nblocks:

wasp-cli chain evm deploy --chainid 537  --gas-per-iota 0 --evm-flavor evmlight --block-keep-amount 1000

For unlimited storage:

wasp-cli chain evm deploy --chainid 537  --gas-per-iota 0 --evm-flavor evmlight --block-keep-amount *

Idea: implement ErgoScript support for IOTA ISCP

ErgoScript is widely known for being lean and light-weight and useful. It is currently implemented on the ERGO blockchain but should basically run on other UXTO protocols as well
and enables many different use cases within the Ergo and Cardano Ecosystem.

ErgoScript Paper

Add Pull request template

Hi 👋🏻

Short question:
Should PRs be made to the develop branch or to the main branch? I guess to develop?

And should the wiki pull the documentation from the develop or main branch?

If you tell me how you want it I can create a PR template for this repo or you can do it yourself of course :)

mint error

I use the wasp-cluster. Balance is 1mi but with mint i get the following error message
error: prepareColoredBalancesOutput: no tokens to transfer

It is not possible to create a wasp node committee with more than one node.

Following the steps in the documentation:
https://github.com/iotaledger/wasp/blob/master/documentation/docs/misc/runwasp.md
https://wiki.iota.org/wasp/misc/runwasp/

4 wasp nodes and 1 goShimmer node are created. All nodes running in a localhost environment.
The 4 wasp nodes successfully connect to goShimmer on port 5000.
The 4 wasp nodes are accessible by http to port 7000/7001 etc showing the properties of the configuration file, config.json.
There is an initialized and funded wallet on each wasp node.

When creating a chain with : ./wasp-cli chain deploy --committee=0,1,2,3 --quorum=3 --chain=mychain --description="My chain"
it returns this error:

2021-08-18T07:59:50+02:00 WARN Peering udp/udpNetImpl.go:347 Dropping handshakeMsg from 127.0.0.1:4000 with pubKey=5gJMq6xhACwMNhmpLjPsNk2zdkc8GZ9x2FKBpN8TEyzC, error=key not found.

This error is displayed on all committee nodes.

But if it is possible to create a chain with a single node and the result is:

./wasp-cli chain deploy --committee=0 --quorum=1 --chain=C3POChain --description="My C3PO chain"
creating new chain. Owner address: 1FiCvsDvyRuh71dgUteG34QRGqCdna2QtKjoy7DVaSELG. State controller: LwxSGyTgo9Z5HxXWSr6YjZ2qww8KGi1EzU4yV5Yvt3tZ, N = 1, T = 1
creating chain origin and init transaction 8TwruvDasfkrky4FYAYcYApnL2Hq5fEgX1HCPXfbbcag.. OK
sending committee record to nodes.. OK
activating chain sfutpoJqUEuoEAxz6WUbqCiXY9cw9Sd4j6NeGFWXiEGb.. OK.
chain has been created successfully on the Tangle. ChainID: $/sfutpoJqUEuoEAxz6WUbqCiXY9cw9Sd4j6NeGFWXiEGb, State address: LwxSGyTgo9Z5HxXWSr6YjZ2qww8KGi1EzU4yV5Yvt3tZ, N = 1, T = 1

This error may be related to #212

iotaledger / wasp Goto Github PK

wasp's Issues

Problem description

Proposed solution

Problem description

Possible solutions

Description

Motivation

Requirements

Are you planning to do it yourself in a pull request?

Recommend Projects

Recommend Topics

Recommend Org