`Invalid blockhash` error while deploying smart contract - solana

I am trying to deploy the demo smart contract on solana for chainlink price feed but getting an error. I followed all the steps from https://docs.chain.link/docs/solana/using-data-feeds-solana/
$ anchor deploy --provider.wallet ./id.json --provider.cluster devnet
Deploying workspace: https://api.devnet.solana.com
Upgrade authority: ./id.json
Deploying program "chainlink_solana_demo"...
Program path: /home/test/solana-starter-kit/target/deploy/chainlink_solana_demo.so...
=============================================================================
Recover the intermediate account's ephemeral keypair file with
`solana-keygen recover` and the following 12-word seed phrase:
=============================================================================
until reason almost can clean wish trend buffalo future auto artefact balcony
=============================================================================
To resume a deploy, pass the recovered keypair as the
[BUFFER_SIGNER] to `solana program deploy` or `solana write-buffer'.
Or to recover the account's lamports, pass it as the
[BUFFER_ACCOUNT_ADDRESS] argument to `solana program close`.
=============================================================================
Error: Custom: Invalid blockhash
There was a problem deploying: Output { status: ExitStatus(unix_wait_status(256)), stdout: "", stderr: "" }.

This is just a timeout error message. It happens from time to time depending on the network availability
Follow these steps and run again. I've also found that you'll want quite a bit more sol in your wallet than you think you need.
To resume a deploy, pass the recovered keypair as the
[BUFFER_SIGNER] to `solana program deploy` or `solana write-buffer'.
Or to recover the account's lamports, pass it as the
[BUFFER_ACCOUNT_ADDRESS] argument to `solana program close`.

Related

Can not deploy my contract on ganache-cli using ETH mainnet fork

I used ganache-cli in combination with my Infura key to fork ETH mainnet so I could use the Uniswap router in my development environment:
ganache-cli --fork https://mainnet.infura.io/v3/<mykeyhere>
This starts my local ganache blockchain without any errors. However when I deploy my contract with truffle:
truffle(development)> deploy
I keep getting the following error:
Compiling your contracts...
===========================
✓ Fetching solc version list from solc-bin. Attempt #1
✓ Fetching solc version list from solc-bin. Attempt #1
> Compiling ./contracts/Migrations.sol
> Compiling ./contracts/MollyCoin.sol
> Artifacts written to /home/dogperson/Code/MollyCoin/build/contracts
> Compiled successfully using:
- solc: 0.6.12+commit.27d51765.Emscripten.clang
UnhandledRejections detected
Promise {
<rejected> CodedError: Given input "NaN" is not a number.
at /home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/handlers/base-handler.js:174:23
at process.promise (internal/process/task_queues.js:97:5)
at ProviderHandler.queueRequest (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/handlers/base-handler.js:178:36)
at ProviderHandler.request (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/handlers/provider-handler.js:58:9)
at earliestBlock (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/persistent-cache/helpers.js:149:5)
at previousClosestAncestor (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/persistent-cache/helpers.js:77:19)
at PersistentCache.cache [as initialize] (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/persistent-cache/persistent-cache.js:142:47)
at Fork.cache [as initCache] (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/fork.js:209:21)
at Fork.fallback [as initialize] (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/fork.js:206:13)
at Blockchain.async [as initialize] (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/blockchain.js:629:22)
at EthereumProvider.async [as initialize] (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/provider.js:195:5)
at Connector.connect (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/connector.js:49:5) {
code: -32000
}
} CodedError: Given input "NaN" is not a number.
at /home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/handlers/base-handler.js:174:23
at process.promise (internal/process/task_queues.js:97:5)
at ProviderHandler.queueRequest (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/handlers/base-handler.js:178:36)
at ProviderHandler.request (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/handlers/provider-handler.js:58:9)
at earliestBlock (/home/dogperson/.nvm/versions/node/v12.22.9/lib/node_modules/truffle/node_modules/ganache/dist/node/webpack:/Ganache/chains/ethereum/ethereum/lib/src/forking/persistent-cache/helpers.js
The contract deploys just fine if I run ganache-cli without --fork. Also if I connect Remix to my forked ganache-cli through Metamask, I am also able to deploy and interact with the contract just fine, which makes me believe that the issue might be with truffle.
Extra info:
Truffle version: 5.5.13
Truffle config file
I tried to do the same thing as you and encountered the same error.
After some research I believe the issue is that ganache is read-only when used to fork mainnet (or any testnet). You can't make any transactions. Only calls.
I was able to achieve the objective by using Hardhat instead of ganache.
First I installed hardhat and initialized the sample project:
https://hardhat.org/guides/project-setup.html
Then I ran hardhat with:
npx hardhat node --fork "https://mainnet.infura.io/v3/<ACCOUNT>"
Then I ran "truffle console" in a separate terminal window, with the following lines in truffle-config.js:
const HDWalletProvider = require('#truffle/hdwallet-provider');
const mnemonic = "test test test test test test test test test test test junk";
module.exports = {
networks: {
development: {
host: "127.0.0.1",
port: 8545,
network_id: "*",
provider: () => new HDWalletProvider(mnemonic, "http://127.0.0.1:8545"),
}
}
}
The mnemonic I used is "test test test test test test test test test test test junk" because that is Hardhat's default mnemonic and I was not immediately able to figure out how to configure Hardhat with a different mnemonic.
Before running the truffle console, remember to install the hdwalletprovider npm package in your truffle directory: https://www.npmjs.com/package/#truffle/hdwallet-provider
At this point I have a running truffle console connected to local hardhat process which is connected to infura. I can make transactions to deploy and interact with contracts.
Hope this helps, and good luck.

Why do I get a "0x1004" when trying to deploy my solana anchor IDL?

When I try to deploy an IDL with anchor, I get a cryptic "Custom Error 0x1004" message. What does this mean:?
$ anchor idl init --provider.cluster testnet --filepath ./target/idl/myprogram.json sa3BafcCxwD6G3tUbvTcvnCD28sCXhpasauLtpw9HdA
Error: Error processing Instruction 0: custom program error: 0x1004
0x1004 is hexadecimal for 4100, or the DeclaredProgramIdMismatch error.
So somewhere in your program, you're declaring a different program id than the one you deployed with:
declare_id!("some_other_program_id"); // this is not your program id!

(AssemblyScript + ReactJS) Can not sign transactions for account test.near on network shared-test

When i run yarn test, i got this error:
Can not sign transactions for account test.near on network shared-test, no matching key pair found in InMemorySigner(UnencryptedFileSystemKeyStore(D:\React Native\Near demo\NEARForum\neardev)).
at Account.signTransaction (node_modules/near-cli/node_modules/near-api-js/lib/account.js:86:19)
at node_modules/near-cli/node_modules/near-api-js/lib/account.js:111:34
at Object.exponentialBackoff [as default] (node_modules/near-cli/node_modules/near-api-js/lib/utils/exponential-backoff.js:7:24)
at Account.signAndSendTransactionV2 (node_modules/near-cli/node_modules/near-api-js/lib/account.js:110:24)
at Account.createAndDeployContract (node_modules/near-cli/node_modules/near-api-js/lib/account.js:208:9)
at LocalTestEnvironment.setup (node_modules/near-cli/test_environment.js:39:9)
someone tell me what i need to config for testing please. Thanks

How to write a policy in .yaml for a python lambda to read from S3 using the aws sam cli

I am trying to deploy a python lambda to aws. This lambda just reads files from s3 buckets when given a bucket name and file path. It works correctly on the local machine if I run the following command:
sam build && sam local invoke --event testfile.json GetFileFromBucketFunction
The data from the file is printed to the console. Next, if I run the following command the lambda is packaged and send to my-bucket.
sam build && sam package --s3-bucket my-bucket --template-file .aws-sam\build\template.yaml --output-template-file packaged.yaml
The next step is to deploy in prod so I try the following command:
sam deploy --template-file packaged.yaml --stack-name getfilefrombucket --capabilities CAPABILITY_IAM --region my-region
The lambda can now be seen in the lambda console, I can run it but no contents are returned, if I change the service role manually to one which allows s3 get/put then the lambda works. However this undermines the whole point of using the aws sam cli.
I think I need to add a policy to the template.yaml file. This link here seems to say that I should add a policy such as one shown here. So, I added:
Policies: S3CrudPolicy
Under 'Resources:GetFileFromBucketFunction:Properties:', I then rebuild the app and re-deploy and the deployment fails with the following errors in cloudformation:
1 validation error detected: Value 'S3CrudPolicy' at 'policyArn' failed to satisfy constraint: Member must have length greater than or equal to 20 (Service: AmazonIdentityManagement; Status Code: 400; Error Code: ValidationError; Request ID: unique number
and
The following resource(s) failed to create: [GetFileFromBucketFunctionRole]. . Rollback requested by user.
I delete the stack to start again. My thoughts were that 'S3CrudPolicy' is not an off the shelf policy that I can just use but something I would have to define myself in the template.yaml file?
I'm not sure how to do this and the docs don't seem to show any very simple use case examples (from what I can see), if anyone knows how to do this could you post a solution?
I tried the following:
S3CrudPolicy:
PolicyDocument:
-
Action: "s3:GetObject"
Effect: Allow
Resource: !Sub arn:aws:s3:::${cloudtrailBucket}
Principal: "*"
But it failed with the following error:
Failed to create the changeset: Waiter ChangeSetCreateComplete failed: Waiter encountered a terminal failure state Status: FAILED. Reason: Invalid template property or properties [S3CrudPolicy]
If anyone can help write a simple policy to read/write from s3 than that would be amazing? I'll need to write another one so get lambdas to invoke others lambdas as well so a solution here (I imagine something similar?) would be great? - Or a decent, easy to use guide of how to write these policy statements?
Many thanks for your help!
Found it!! In case anyone else struggles with this you need to add the following few lines to Resources:YourFunction:Properties in the template.yaml file:
Policies:
- S3CrudPolicy:
BucketName: "*"
The "*" will allow your lambda to talk to any bucket, you could switch for something specific if required. If you leave out 'BucketName' then it doesn't work and returns an error in CloudFormation syaing that S3CrudPolicy is invalid.

Error starting hyperledger-composer network after Fabric and Composer version upgrade

I've come across an error starting the hyperledger-composer network that isn't answered in the composer-wiki.
✖ Starting business network definition. This may take a minute...
Error: Error trying to start business network. Error: No valid responses from any peers.
Response from attempted peer comms was an error: Error: transaction returned with failure: can't find PEM header: undefined
Command failed
Checking pre-requisites,
Fabric 1.2
Composer 0.20.4
Node 8.12.0
Docker 18.01.1
"composer network install" was successful, with file appearing in the docker peer at /var/hyperleder/production/chaincodes
After running the "composer network start" command, a "docker ps" shows new docker instance with name:
dev-peer0.org1.example.com-<<business-network-name>>-0.0.7
But any attempt to ping this results in a failure like this:
Error: Error trying to ping. Error: make sure the chaincode <<business-network-name>> has been successfully instantiated and try again: getccdata composerchannel/<<business-network-name>> responded with error: could not find chaincode with name '<<business-network-name>>'
Checking the log of the dev-peer0, it ends with the following:
2018-11-05T05:03:18.227Z [4264161f] ERROR :Composer :Init() can't find PEM header: undefined
2018-11-05T05:03:18.227Z [4264161f] VERBOSE :Composer :#PERF Init() Total (ms) duration for txnID [4264161fc30a61c70884d4c7efb460fea6a755d07bc4852875c393346795227a]: 929.00
2018-11-05T05:03:18.228Z ERROR [lib/handler.js] [composerchannel-4264161f]Calling chaincode Init() returned error response [can't find PEM header: undefined]. Sending ERROR message back to peer
The corresponding error in the peer0 log is a big larger:
2018-11-05 05:03:18.229 UTC [endorser] SimulateProposal -> ERRO 439d [composerchannel][4264161f] failed to invoke chaincode name:"lscc" , error: transaction returned with failure: can't find PEM header: undefined
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:202
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:131
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:173
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
2018-11-05 05:03:18.229 UTC [endorser] SimulateProposal -> DEBU 439e [composerchannel][4264161f] Exit
Since this last worked I have updated composer from 0.19 to 0.20.4, and taken Fabric from 1.1 to 1.2.
Googling suggests that this kind of error "can't find PEM header: undefined" is associated with a change in key signing. After tearing down Fabric I re-ran ./createPeerAdminCard.sh - is there another card or similar that needs to be re-created to accomodate the latest versions?
Thanks to #R Thatcher for putting me onto the right direction. This was all down to mismatching cards, and was resolved by clearing out everything and starting again.
Specifically, in /fabric-dev-servers:
./stopFabric.sh
./teardownFabric.sh
composer card list
composer card delete -c admin#<business-network-name>
composer card delete -c PeerAdmin#hlfv1
./startFabric.sh
./createPeerAdminCard.sh
Then changing into the composer/business-network-name directory:
composer network install --card PeerAdmin#hlfv1 --archiveFile business-network-name\#0.0.7.bna
composer network start -c PeerAdmin#hlfv1 -n business-network-name -V 0.0.7 -A admin -S adminpw --file networkadmin.card
composer card import --file networkadmin.card --card admin#business-network-name
composer network ping -c admin#business-network-name
So yes, it was about mismatching cards and not cleaning these up as part of a new deployment.
Although not part of the original problem, it's also worth noting that the -A and -S parameters of the composer network start command HAD to be set to admin and adminpw respectively. See composer issue #3781.
Answering the the last remark from #Capn Sparrow
"the -A and -S parameters of the composer network start command HAD to be set to admin and adminpw respectively."
This is the correct and expected behaviour :-)
with the composer network start command the -A and -S are specifying an existing user in the CA that we want a new set of Credentials (certificate and keys) for which is then bound to a Composer System participant.
When you use the 'standard development fabric' this has a CA configured with a user called 'admin' with a secret of 'adminpw'. If you had build your own Fabric from scratch you could choose the name and secret of your first default user. Alternatively you could work with the fabric-ca client software to create additional users in the CA.

Resources