I accept no responsibility for loss of funds, or any perceived negative consequences that happens as a result of this code. It has not been audited use at your own risk
Due to the way Aurora works, each contract can only burn a certain amount of gas. Because of this we need to be able to optimize the way to send transactions. Using the following it's possible to claim all liquidity mining rewards from all realms in three transactions. Using this method you can send a max of 3 transactions, as opposed to the 8 that would be required harvesting rewards individually. This does not claim staking rewards given out by the kingdom.
Assuming a cost of 6 cents per transaction, using this method will save you approximately 30 cents in gas fees, allowing for quicker ROI when farming bastion.
Using newer compiler versions and the optimizer gives gas optimizations and additional safety checks for free!
The advantages of versions 0.8.* over <0.8.0 are:
- Safemath by default from
0.8.0(can be more gas efficient than some library based safemath). - Low level inliner from
0.8.2, leads to cheaper runtime gas. Especially relevant when the contract has small functions. For
| apiVersion: apps/v1 | |
| kind: Deployment | |
| metadata: | |
| name: temporal | |
| labels: | |
| name: temporal | |
| spec: | |
| replicas: 1 | |
| selector: | |
| matchLabels: |
| // Model to represent an account in the distributed database | |
| // Accounts are mainly a place users can store information like their private keys, in a password protected | |
| // vault, so they can login conveniently from other devices and keep hold of their private keys and record | |
| // what blogs they are authors of. It's also a way for other users to lookup an authors public keys to validate | |
| // their other objects when determining if a new version of some data really belongs to the blog it claims to be | |
| // related to. | |
| const nacl = require('tweetnacl') | |
| const cbor = require('borc') | |
| class HSAccount { |
Try out Testlab on your own machine using Vagrant and Virtualbox.
18 minutes, 233 MB
| zenground0 [2:07 PM] | |
| The first one is whether a libp2p host will advertise its (pid, multiaddr) mapping in a networks' DHT after constructing the node with a `libp2p.Routing(makeDHT)` option. | |
| Right now this is all we do in the filecoin network and we don't seem to be advertising id,addr records in the dht. | |
| Wondering if we're missing an obvious `provideRouteToMe` call or something like that | |
| anacrolix [2:11 PM] | |
| I’ll have to check, but a typical DHT will routinely reestablish its own presence to nearby peers, and announce itself during bootstraps. | |
| In the context of libp2p, that should include the peer ID and routing information like multiaddrs | |
| zenground0 [2:12 PM] |
| # Sysctl Configuration for High-Performance such as API/Web Server | |
| # Kawin Viriyaprasopsook <[email protected]> | |
| # place file in /etc/sysctl.d/60-sysctl.conf | |
| # and run `sysctl --system` | |
| # -------------------------------------------------------------------- | |
| # System options | |
| # -------------------------------------------------------------------- | |
| # Reduce kernel messages on console (3 4 1 3) |
