Nice! Here are my “first hands on” experience: https://github.com/OpenZeppelin/starter-kit/issues/60. Few issues and misunderstandings but works like charm now.
Hi @lukaslukac welcome to the community 
Thanks for writing up your hands on experience with the Gas Station Network starter kit. I moved this to it’s own topic.
Some great feedback. Glad you got it working.
The GSN Starter Kit uses OpenZeppelin SDK which is why you didn’t find Truffle Migrations.sol or a migrations script.
You can deploy the Counter.sol contract using oz create and use the interactive commands, making sure you call initialize.
$ oz create
✓ Compiled contracts with solc 0.5.11 (commit.c082d0b4)
? Pick a contract to instantiate Counter
? Pick a network development
✓ Contract Counter deployed
All contracts have been deployed
? Do you want to call a function on the instance after creating it? Yes
? Select which function * initialize(num: uint256)
? num (uint256): 27
✓ Instance created at 0x966d3e76E7a890A2d7B9AE1E370dC219E920F9D4
0x966d3e76E7a890A2d7B9AE1E370dC219E920F9D4
1 Like
Hi @lukaslukac
To make it easier for the community (and as I hadn't done it myself) I created a guide to use the Gas Station Network starter kit on a local network.
Feel free to feedback on anything that could be improved to make the experience better.
1 Like
Thanks for the warm welcome Andrew!
The oz create explains things 
I didn’t see it in the documentation. I am familiar with OpenZeppelin famous collection of smart contracts but not with your SDK. Maybe it would be nice to mention this directly in the GSN docs for devs new to OZ ecosystem like me.
Thanks again! Today I will replace the Counter.sol with one of the Lightstream’s Smart Vault SC for ACL management and I am happy to come back and share more integration feedback to improve your kit.
Have a great day @abcoathup!
2 Likes
Awesome @lukaslukac.
It’s a great point that the starter kit assumes familiarity with OpenZeppelin SDK, so definitely something to improve on.
When you get a chance, would you mind sharing what you are working on.
Great to have you part of the community.
I learned a lot of Solidity from your Github SCs a year ago but had no idea about your SDK actually.
Will do, on Monday/Tuesday.
1 Like
And one quick question, is there a way the Counter.sol would be deployed by the user itself for free? Maybe by creating a CounterDeployer.sol, a factory pattern, that would deploy new instances of Counter.sol?
2 Likes
Hi @lukaslukac
Given that the Gas Station Network is used for transactions then it could be used for transactions to create contracts from a factory.
yep, working on it. Let’s see how it goes.
@abcoathup the gsn-relayer is a server written in Go. I can see the binary is downloaded from a repository release section but I can’t find its source code. Could you share the source code link please?
2 Likes
I think I found it finally. This one? https://github.com/tabookey/tabookey-gasless/blob/master/server/src/relay/RelayHttpServer.go
I will be just posting to this thread all the issues I come along because they are keep popping up and it’s bit frustrating. It will help me articulate the progress better and you to improve the UX. Please don’t take it as complaining
I want to deploy my own RelayHub at Lightstreams Standalone network on my local with different “from” address but this part of the code won’t let me as the data field is hardcoded, to field is hardcoded + no way to change gas price. The default gas price of the network should be taken.
await web3.eth.sendTransaction({ from, to: data.relayHub.deploy.deployer, value: ether(data.relayHub.deploy.fundsEther) });
data obj:
deploy: {
deployer: '0xff20d47eb84b1b85aadcccc43d2dc0124c6211f7',
fundsEther: '0.42',
tx:
I am thinking of using a different repository to deploy the RelayHub but I am not sure if it’s the good source of truth as it’s a beta branch: https://github.com/tabookey/tabookey-gasless/blob/v0.4.0-beta2/migrations/2_deploy_contracts.js
2 Likes
github.com/openzeppelin/starter-kit-gsn/node_modules/@openzeppelin/contracts-ethereum-package/contracts/GSN this directory is missing the RelayHub SC so I can’t deploy it. Seems like I will go with previously mentioned tabookey.
cd /Users/enchanterio/go/src/github.com/tabookey/tabookey-gasless
I have to switch to old Node otherwise compilation fails:
nvm use v10.13.0
Installing modules:
yarn install
Compiling SCs:
truffle compile
Unlocking deployment acc…
Configuring custom network in truffle.js:
standalone: {
verbose: process.env.VERBOSE,
host: "127.0.0.1",
port: 8545,
network_id: "*",
from: "0xc916cfe5c83dd4fc3c3b0bf2ec2d4e401782875e"
},
Running migration
truffle migrate --network=standalone
Error: Transaction underpriced… hmm again wtf. Why truffle didn’t take the default network min tx price… well, let’s hardcode it… update to come
Failed. Figuring why… did I skip a step? Probably the ABI is different or some argument is hardcoded somewhere:
starter-kit-gsn $npx oz-gsn run-relayer --ethereumNodeURL=http://localhost:8545 --relayHubAddress=0x0C6EbAc3bF8D780EE8F7ae03A266590934F1D466 --workdir=/Users/enchanterio/.lightchain_standalone/relayer --no-devMode
Starting relayer
/Users/enchanterio/Library/Caches/gsn-nodejs/gsn-relay-v0.1.4
-EthereumNodeUrl http://localhost:8545
-RelayHubAddress 0x0C6EbAc3bF8D780EE8F7ae03A266590934F1D466
-Port 8090
-Url http://localhost:8090
-GasPricePercent 0
-Workdir /Users/enchanterio/.lightchain_standalone/relayer
2019/08/22 16:36:15 RelayHttpServer.go:44: RelayHttpServer starting. version: 0.4.0
2019/08/22 16:36:15 RelayHttpServer.go:217: Using RelayHub address: 0x0C6EbAc3bF8D780EE8F7ae03A266590934F1D466
2019/08/22 16:36:15 RelayHttpServer.go:218: Using workdir: /Users/enchanterio/.lightchain_standalone/relayer
2019/08/22 16:36:15 RelayHttpServer.go:228: Constructing relay server in url http://localhost:8090
2019/08/22 16:36:15 utils.go:40: ks accounts len 1
2019/08/22 16:36:15 utils.go:66: key extracted. addr: 0xF3d59B193f3C9DCfD054466E01063c8bD68344f6
2019/08/22 16:36:15 RelayHttpServer.go:230: relay server address: 0xF3d59B193f3C9DCfD054466E01063c8bD68344f6
2019/08/22 16:36:15 RelayHttpServer.go:62: RelayHttpServer started.Listening on port: 8090
2019/08/22 16:36:15 RelayHttpServer.go:308: Waiting for stake...
2019/08/22 16:36:15 RelayHttpServer.go:308: Waiting for stake...
2019/08/22 16:36:15 RelayHttpServer.go:308: Waiting for stake...
2019/08/22 16:36:17 RelayHttpServer.go:131: address 0xF3d59B193f3C9DCfD054466E01063c8bD68344f6 sent
Funding GSN relay at http://localhost:8090
2019/08/22 16:36:17 RelayHttpServer.go:131: address 0xF3d59B193f3C9DCfD054466E01063c8bD68344f6 sent
Could not connect to node at http://localhost:8545 (Error: Failed to fund relay: 'Error: Transaction has been reverted by the EVM:
{
"blockHash": "0x7bf58596d4889617d64266d58080f659c1ef7ec2d4af52c7c4ed94917eaa7ceb",
"blockNumber": 662,
"contractAddress": null,
"cumulativeGasUsed": 90000,
"from": "0xc916cfe5c83dd4fc3c3b0bf2ec2d4e401782875e",
"gasUsed": 90000,
"logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"status": false,
"to": "0x0c6ebac3bf8d780ee8f7ae03a266590934f1d466",
"transactionHash": "0xe351390ffa51f02e48804b8eab359a9ef42c2359428b09ff181b7db7a9d18d77",
"transactionIndex": 0,
"events": {}
}').
The above error is very misleading “could not connec to node”… yes it could, there is “just” a TX error. The message is hardcoded in run-relayer.js
console.error(`Could not connect to node at ${program.ethereumNodeURL} (${err}).`);
Investigating more, the naming of concepts is bit confusing to me.
- function name says: “register”
- action is performing: “staking”
- error thrown “funding error”
Okay seems it’s a staking SC error because of a wrong state. Many require statements. In order to stake a relayer, I have to register it… makes sense. But to register it, it has to run. Infinite error loop…
starter-kit-gsn $npx oz-gsn register-relayer --ethereumNodeURL=http://127.0.0.1:8545 --relayHubAddress=0x0C6EbAc3bF8D780EE8F7ae03A266590934F1D466
(node:2899) UnhandledPromiseRejectionWarning: Error: Could not reach the relay at http://localhost:8090, is it running?
This is not gonna work. It keeps using precompiled downloaded image. Why 95% of the project is in JS and the RelayServer is in Go? I am a Go developer but I can’t see a point in this. A NodeJS launching a Go server to serve some responses? Why? I can’t neither compile the Go server easily because of the way it’s done.
Hmmm… I am getting tired. @abcoathup do you have any idea where to go from here?
1 Like
Hi @lukaslukac
Great to see you diving in to use Gas Station Network.
Manual setup for setting up a relayer:
For deploying a new hub:
Oh you made my day. The nginx relayer instructions worked very well!!! Now I have a hub and a relayer. Gonna continue with setup.
3 Likes
Hi @lukaslukac
Good to hear that you are making progress. 
Hey @abcoathup Another day fighting Some extra feedback, the Relayer HTTP Server would need to be re-written and provide better logging and statuses. It’s not the best code to be honest and makes the debugging really hard. Also all the global variables https://github.com/tabookey/tabookey-gasless/blob/master/server/src/relay/RelayHttpServer.go#L28 … no bueno If you want, I can give u a hand with some code improvements as a Go dev.
The reason I am suggesting that is because the Relayer server returns the following response:
{"RelayServerAddress":"0x26e773141975416bd44be64ef5e9f0e6ee94f6aa","MinGasPrice":0,"Ready":false,"Version":"0.4.0"}
Ready: “false”. Why?
I was able to scrap the logs and it seems like the Relayer is funded and Staken correctly:
Relay funded. Balance: 1000000000000000000000
Aug 26 14:48:27 localhost RelayHttpServer[22049]: 2019/08/26 14:48:27 RelayHttpServer.go:290: Updating unconfirmed txs...
Any idea why it’s still not “ready”? It’s difficult to reverse-engineer this code as the global variable is changed in several different parts of code.
Thx, hope you started the week well after Berlin trip!
3 Likes
Wow @lukaslukac, thanks so much for being so thorough and patient! This sort of feedback is extremely useful for us to help identify the main pain points of users, and bits that are not properly covered in our guides.
Could you clarify what it is you want to change from the deployment process? The reason why those fields are hardcoded is due to the way RelayHub is deployed, which lets us have the contract be stored at the same address on all networks. See here for more details into how this is done and why.
The from argument of that function is slightly misleading: it won't be that account that actually deploys the contract, but rather the one that funds the deployer account. In any case, you shouldn't need to change this behavior.
Thanks for spotting this! I'm in the middle of a light refactor to the helpers which should make this better 
Hm, good catch. We're trying to hide the complexities behind the spinning up of a new relayer by simply calling this 'register', but this is actually three steps: staking, funding and registering. I'll take a look at those error messages to see how we can improve this.
Historical reasons, most of the development of the relayer server was made by the TabooKey team, and they chose Go for portability.
We do plan on rewriting the server in Node, since the code is rather simple and the Go project carries quite a bit of technical debt from having been so heavily modified over the last months, but this is not on our immediate roadmap.
If you're able to open PRs on the TabooKey repo targetting these issues, that'd be awesome!
Have you properly registered the relayer? That process needs to complete before it's able to serve any requests.
That said, there seems to be an issue with the ready field, since our own relayer servers randomly go down for a couple minutes and then get fixed with no intervention, but I doubt this is the same problem you're facing.
2 Likes