r5.2xlarge instance in eu-west-1 with 200 GB EBS io1 volume and 3000 IOPS.
pragma solidity ^0.5.0; | |
contract EIP712 { | |
mapping(address => uint256) public nonces; | |
struct EIP712Domain { | |
string name; | |
string version; | |
uint256 chainId; |
// ExecuteCommand - execute cmd *exec.Cmd with async output from command stderr, stdout | |
// and return combine output as some byte-buffer object | |
// 1st, 2nd writers - always stdout, stderr | |
func ExecuteCommand(cmd *exec.Cmd, writers ...io.Writer) (buff *Buffer, err error) { | |
var wg sync.WaitGroup | |
var outputWriter, errorWriter io.Writer | |
buff = NewBuffer() | |
// Stdout redirect |
{ | |
"config": { | |
"chainId": 99, | |
"homesteadBlock": 1, | |
"eip150Block": 2, | |
"eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000", | |
"eip155Block": 3, | |
"eip158Block": 3, | |
"byzantiumBlock": 4, | |
"clique": { |
Just documenting docs, articles, and discussion related to gRPC and load balancing.
https://github.com/grpc/grpc/blob/master/doc/load-balancing.md
Seems gRPC prefers thin client-side load balancing where a client gets a list of connected clients and a load balancing policy from a "load balancer" and then performs client-side load balancing based on the information. However, this could be useful for traditional load banaling approaches in clound deployments.
https://groups.google.com/forum/#!topic/grpc-io/8s7UHY_Q1po
gRPC "works" in AWS. That is, you can run gRPC services on EC2 nodes and have them connect to other nodes, and everything is fine. If you are using AWS for easy access to hardware then all is fine. What doesn't work is ELB (aka CLB), and ALBs. Neither of these support HTTP/2 (h2c) in a way that gRPC needs.
... | |
class UpdatePersonName(graphene.Mutation): | |
class Input: | |
uuid = graphene.Int(required=True) | |
name = graphene.String(required=True) | |
person = graphene.Field(Person) |
# Kernel sysctl configuration file for Linux | |
# | |
# Version 1.12 - 2015-09-30 | |
# Michiel Klaver - IT Professional | |
# http://klaver.it/linux/ for the latest version - http://klaver.it/bsd/ for a BSD variant | |
# | |
# This file should be saved as /etc/sysctl.conf and can be activated using the command: | |
# sysctl -e -p /etc/sysctl.conf | |
# | |
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and sysctl.conf(5) for more details. |
/** | |
* Base contract that all upgradeable contracts should use. | |
* | |
* Contracts implementing this interface are all called using delegatecall from | |
* a dispatcher. As a result, the _sizes and _dest variables are shared with the | |
* dispatcher contract, which allows the called contract to update these at will. | |
* | |
* _sizes is a map of function signatures to return value sizes. Due to EVM | |
* limitations, these need to be populated by the target contract, so the | |
* dispatcher knows how many bytes of data to return from called functions. |
If you use Amazon AWS for nearly anything, then you are probably familiar with KMS, the Amazon Key Management Service.
KMS is a service which allows API-level access to cryptographic primitives without the expense and complexity of a full-fledged HSM or CloudHSM implementation. There are trade-offs in that the key material does reside on servers rather than tamper-proof devices, but these risks should be acceptable to a wide range of customers based on the care Amazon has put into the product. You should perform your own diligence on whether KMS is appropriate for your environment. If the security profile is not adequate, you should consider a stronger product such as CloudHSM or managing your own HSM solutions.
The goal here is to provide some introductory code on how to perform envelope encrypt a message using the AWS KMS API.
KMS allows you to encrypt messages of up to 4kb in size directly using the encrypt()/decrypt() API. To exceed these limitations, you must use a technique called "envelope encryptio