EOS New York is proud to present our information for the first checkmark report administered by EOS Go. We support @EOSGo in their effort to provide the community with a digestible and transparent method of evaluating Block Producer candidates. Voting is tremendously important for the success of EOS.
Please see our “Your Vote Matters” series #1 & #2 for more information. Be sure to check out our initial roadmap as well for a detailed look at our plans.
You can also check out our original introduction post to the community, the first western block producer to do so.
Public Presence
EOS New York Website
Twitter
STEEM
Medium
Meetup
Telegram
Join our mailing list at "Get Updates"
Identification on Steemit
Official Block Producer Candidate Name
EOS New York
Location of Company Headquarters
We are a globally decentralized team and do not operate out of one physical location.
Expected Location of Servers
Eastern North America with backups in international jurisdictions. We will not be exclusively running servers in North America for security and geo-diversity purposes.
Type of Servers
- Phase 1 - Multi-cloud solution for launch, ramp up, and testing
- Phase 2 - Bare metal with multi-cloud failover processes
Current Employee List and Pictures of at least 67% of Staff
Kevin Rose - Co-Founder & Head of Community
Rick Schlesinger - Co-Founder & Head of Strategy
Buddy Deck - Head of Block Production
Mike Haggerty - Lead Software Developer
Relevant Background Qualifications of Staff
Kevin Rose - Co-Founder & Head of Community
Kevin Rose leads Community efforts at EOS New York helping build the EOS community and ensuring that the values and goals of EOS New York and the community are aligned. He has lead nationwide marketing campaigns at major auto manufacturers like Ford, Toyota, & MINI Cooper and co-founded a digital product design firm. Delivering transparency and tangible value to the communities that he helps build is at the core of everything he does. He is a passionate blockchain enthusiast and evangelist and participated with others in the first community-driven test net of the EOS Dawn 2.0 software in January of 2018.
Rick Schlesinger - Co-Founder & Head of Strategy
Rick leads the EOS New York block production business strategy and oversees operations across capital investments, governance, finance, and legal. Rick co-founded EOS New York after a successful career in management consulting advising Fortune 500 companies on business strategy and M&A. Rick has been following blockchain technology since 2010 after learning about the interesting economic incentives the Bitcoin protocol created for its users. Rick is a student of economics and libertarian philosophy and envisions a blockchain enabled world will create freer societies, institutions, and people.
Buddy Deck - Head of Block Production
William "Buddy" Deck leads the technology efforts at EOS New York and is designing the infrastructure that will support the EOS.IO software. He has spent the past three years honing his skills working with (AWS/onsite) HPC and (GPFS and Lustre) storage systems for a leading financial firm. Before that he spent five years working on a high speed networking stack for mainframe systems used by banks and government agencies. He has extensive experience with programming, data processing, performance monitoring, and web services. He participated in the launch of the EOS Dawn 2.0 community test net and is excited to see the community grow.
Mike Haggerty - Lead Software Developer
Mike is a software engineer with 12 years of application development experience. He has worked with non-profits, governments, and publicly traded companies from initial design through to deployment and all stages in between. While Mike has endured codebases comprised primarily of VB6, he is happiest working with cutting-edge technologies such as Docker, AngularJS, React, Node.js, and (of course) EOS.IO. Mike has enjoyed expanding his Linux and AWS skill set while partnering with EOS community members from around the world to help launch the EOS Dawn 2.0 community test-net.
Technical Specifications (Launch): Github
Block Producing Node
These specs are specifically for launch and are not intended to be long term. We do not estimate heavy use on the network for the first 30 days as private keys are imported and dApps begin to test in live environments. We will scale as necessary as network use increase. We could easily be running 10x the capacity but we value efficiency when it comes to block rewards.
Specifications
OS: Linux Distro
vCPU: 8
RAM: 256 - 512
Storage: 512GB SSD (blocks), 1TB HDD for IPFS
Network: 1 Gbps (and will scale up as necessary)
Location
In order to scale rapidly and stay agile in the fragile period immediately following launch we will be running our initial producing node in a cloud environment in North America. This environment will also allow us to do additional software and hardware testing which will be used to form the requirements for our future planned co-located and/or owned data center facility.
Security:
We plan on locking this node down using a variety of custom software stacks, built-in unix tools, and industry standards. As this is the flagship node, security is of the utmost importance. We also plan on working together with other block producers and various security professionals to produce a white paper on configuration and securing a producing node.
Non-Producing Node(s):
This node(s) will be a load balanced node(s) used by dApps/users to query the blockchain. These will be publicly reachable via the load balancing node. The idea is to separate and isolate the producing node as much as possible to ensure maximum uptime. The second responsibility of these nodes is to work as a backup to the producing node in case of a security compromise or software/network failure.
Specifications
OS: Linux Distro
vCPU: 8
RAM: 256 - 512
Storage: 512GB HDD (blocks), 1TB HDD for IPFS
Network: 1 Gbps (and will scale up as necessary)
Location
Resides in the same cloud region as the main block producing node.
Security
These boxes will be public facing so they will be less constrained than the BP node however connections to the BP node will be locked down in case of compromise.
Offsite Backup(s)
These node(s) will be additional standby nodes that are constantly syncing the chain. However, they will reside in different geographical and jurisdictional locations outside of the main Block Producing cloud and other non-producing nodes. These boxes will remain in the cloud however we will be using different providers to allow for handling the catastrophic failure of a specific cloud region or of a specific cloud-provider as a whole.
Specifications
OS: Linux Distro
vCPU: 8
RAM: 256 - 512
Storage: 512GB HDD (blocks), 1TB HDD for IPFS
Network: 1 Gbps (and will scale up as necessary)
Location
TBD. At least one will reside outside of North America and in other cloud providers than the main BP node.
Security
These boxes will be public facing so they will be less constrained than the BP node however connections to the BP node will be locked down in case of compromise.
Security
The security of the BP node is of the utmost importance. Our aim as a Block Producer is to never miss a block. We will implement a whitelist firewalled approach to locking down BP nodes. This will require a greater understanding of the port needs of the eosiod as well as the eosioc so the approach will mature with the software. Outside network attacks are expected so we plan on using an immutable server infrastructure. Whether in the cloud or in our own data center we believe this is going to become best practice. This architecture requires that the monitoring and failovers work flawlessly as any change to the server will require a failover and a rebuild. This extra work is something we think is necessary to the overall security of the ecosystem.
Automation
Maintaining a consistent configuration across the entire system and the ability to failover in the event of catastrophic failure is imperative to the success of any distributed system.
Configuration
Good configuration management has been the norm in data centers of all sizes for years and our infrastructure will operate with the same ethos. We have been involved with over four separate test nets to date and have worked to create automation scripts to push changes in configuration and software. This work will continue as we move into our production environment.
Failover
As uptime is a metric that we consider to be a top priority we will be creating an automatic failover system from the main BP node to the non-producing nodes. If our cloud provider goes down in a certain region we will have scripts in place to failover to a completely different provider in a different region. These failovers will be tested thoroughly using other cloud instances and an EOS testnet (either community or our own.
Monitoring
A constant eye on the system's performance is essential in determining at which point a failover is required. To this end we will be implementing monitoring of all important system metrics as well as looking to pull in any relevant eosiod stats.
Future Plans
Scaling
The first few months of block producing will require an environment that can scale quickly with changing requirements. Whether that is scaling the main producer node to handle multithreading or scaling out storage to handle IPFS integration. To this end we believe that our monitoring and knowledge around the community will allow us to scale as needed.
Colocation
As soon as the mainnet testing is sufficient and the network as a whole appears relatively stable, we will begin migrating to bare metal data centers in Q3 2018 (pending). While we believe in the agility the cloud offers us in the crucial infancy of this endeavor, we have heard from from the community and see for ourselves that moving to our own secured, geographically diverse locations is in the best long term interest for the EOS network.
Cloud
We plan on moving out of the cloud with our main block producing node but the cloud will continue to be part of our capacity. Possible cloud used are: dApp development testnet, for our partners, or for elastic capacity for our main data center. We view the cloud as a valuable tool in our total service offering.
Multithreading
As we learn more about the multithreading aspects of the software stack we plan on adjusting our design. We believe our elastic approach will easily handle any software stack changes.
Scaling Plan
Per our roadmap release we will be operating in the cloud with multiple providers in multiple regions until at least the beginning of Q3 2018. Up to this point, we will have been working on exploring bare metal solutions at facilities we will either construct or co-locate within. Once we have a “go” on the bare metal solutions we will shift our producing node away from the cloud and will then have a hybrid solution in place. Please see our full roadmap post for more information on our milestones.
Community Benefit Projects
EOS Resource Planner
On March 26th we announced our intention to build the EOS Resource Planner or ERP. This tool will answer the question, “How many EOS tokens do I need to power my idea?”. Please see the full post for more information.
Monthly Meetups
We host monthly meetups in Manhattan for the EOS New York meetup group which currently sits at just under 700 members. We have plans to expand meetups outside of Manhattan.
Example: Meetup recap with Thomas Cox
Meetup link
EOS Education & Marketing Materials
Once elected we will begin production of marketing materials to evangelize EOS within the US market. Please see more information in the Q2 2018 section of our roadmap.
dApp Advisory & Assistance
We announced that dApp assistance is a top priority for EOS New York, only second to building out the network infrastructure itself. We are currently acting as an advisor for a very promising dApp and will announce this partner closer to launch. There are other incubation plans in the works that we are not ready to disclose at this time.
Contact Information
Telegram usernames:
EOS New York Telegram: EOS New York Chat
Kevin Rose
Rick Schlesinger
Buddy Deck
Mike Haggerty
Test Networks:
Network: Superhero
Node Name: Ironman
Network: EOSNet
Node Name: Otho
EOS New York is a Block Producer Candidate. Always adding value. Everything a Block Away
Great post @eosnewyork, thank you for making this easier to track for the block producer report.
We appreciate the effort your team puts in to provide value for other candidates and the community; we're all stronger when the envelope is pushed and you guys are doing a great job. Go EOS!
Thank you @eosgo!
Congrats!
That is amazing and great work.
Eos=future!