| # Frontend Design Guideline | |
| This document summarizes key frontend design principles and rules, showcasing | |
| recommended patterns. Follow these guidelines when writing frontend code. | |
| # Readability | |
| Improving the clarity and ease of understanding code. |
| set your private key and validator address as a env. (If you don't know where your private key is, it is in a file called validator.key. or it should also be included in the mail you received during onboarding. ) | |
| PRIVATE_KEY="PUT YOUR PRIVATE KEY HERE" | |
| VAL_ADDRESS="PUT YOUR VALIDATOR ADDRESS HERE" | |
| All steps are necessary. | |
| - Step 1 |
I'm a [Your Job Title], currently working at [Your Company Name]. I have [Number of Years of Experience] years of experience in [Your Field of Expertise].
Syncing an Ethereum node is largely reliant on latency and IOPS, I/O Per Second, of the storage. Budget SSDs will struggle to an extent, and some won't be able to sync at all. IOPS can roughly be used as proxy of / predictor for latency. Measuring latency directly is arguably better.
This document aims to snapshot some known good and known bad models.
The drive lists are ordered by interface and then by capacity and alphabetically by vendor name, not by preference. The lists are not exhaustive at all. @mwpastore linked a filterable spreadsheet in comments that has a far greater variety of drives and their characteristics. Filter it by DRAM yes, NAND Type TLC, Form Factor M.2, and desired capacity.
For size, 4TB is a conservative choice which also supports a Fusaka "supernode". The smaller 2TB drive should last an Ethereum full node until at least sometime 2026, with [pre-merge history expiry](http
| #!/bin/bash | |
| curl -s http://localhost:26657/dump_consensus_state | jq '.result.round_state.votes[0].prevotes' | awk '{print $1}' | grep -i "\"V" | cut -f 2 -d':' | sort > votedadresses | |
| while read line; do curl -s http://localhost:26657/dump_consensus_state -s | grep $line -A4 | grep "\"value\"" |head -n1 | awk '{print $2}' >> votestkeys; done < votedadresses | |
| curl -s http://localhost:26657/dump_consensus_state | grep "value" | awk '{print $2}' | sort |uniq > allvotes | |
| while read line; do sed -i -e "s#$line##g" allvotes;done < votestkeys | |
| cat allvotes | sort > filterednovotes | |
| sed -i -e '/^[[:space:]]*$/d' filterednovotes | |
| sed -i -e 's/"//g' filterednovotes | |
| while read line; do gravity query staking validators --limit 1000 | grep $line -A11 | grep moniker; done < filterednovotes |
| func SendPushNotification(deviceTokens []string) error { | |
| decodedKey, err := getDecodedFireBaseKey() | |
| if err != nil { | |
| return err | |
| } | |
| opts := []option.ClientOption{option.WithCredentialsJSON(decodedKey)} | |
| app, err := firebase.NewApp(context.Background(), nil, opts...) |
This article describes the Minglejingle (MJ) protocol: a redesign of Mimblewimble (MW) for non-interactive transactions. It preserves the security and privacy properties, supports payment proofs, non-interactive coinjoin and secure pruning of spent outputs.
Blockchains are distributed ledgers that preserve the transaction history so that new network participants can, at any point in the future, verify these two security properties:
| # ================================================================================================== | |
| # | |
| # NOTICE | |
| # | |
| # This gist is no longer maintained. It was moved to repo: | |
| # | |
| # https://github.com/maratori/golangci-lint-config | |
| # | |
| # Full history and all v2 releases are preserved in the repo. | |
| # |
Bucket policy is an access policy available for you to grant anonymous permissions to your Minio resources. Bucket policy uses JSON-based access policy language.
This section presents a few examples of typical use cases for bucket policies. The policies use testbucket strings in the resource value. To test these policies, you need to replace these strings with your bucket name. For more information please read Amazon S3 access policy language
The following example policy grants the s3:GetObject permission to any public anonymous users. This permission allows anyone to read the object data under testbucket, which is useful for when you have publicly readable assets. A typical example is a website assets stored in testbucket.
