Company
B-Harvest first participated in cosmos gaia-500x in 2018, and has maintained a stable network for 3 years in more than 10 networks so far. In addition to the validator business, we have made many technological contributions to the entire blockchain ecosystem. For example, we added many features to Tendermint Core.
Recently the whole team joined Tendermint, creating gdex and Emeris. We also contributed to security auditing and bug finding of core functional codes on other chains such as Kava and Terra. Furthemore, we have a very large ecosystem community in Korea, and we have led the community through various opinions in the global DeFi group and actively participated in governance.
β site : https://bharvest.io/
Experience
The network weβre participating in.
COSMOS , TERRA(1~2nd Rank) , KAVA ,OSMOSIS, E-MONEY, BAND-PROTOCAL, CHAIN-LINK, Elrond, IRIS, ORBIT, SYMBOL , SECRET-NETWORK, Sentinel, RIZON(HDAC), AXELAR, TRGADE
We have made various contributions.
β Cosmos GOS 2nd,
β Cosmos GOZ Liveness Reward
β Secret network Hackathon Winner
β Terra Hackathon Winner
β Cosmos Hackathon Winner
β COSMOS GDEX Trading Competitors
β Tendermint Gdex Creator
β KAVA CDP Auditing
β TERRA ORACLE BUG Auditing
β Tendermint Feature Contribution( validator key rotation system, peer priority connectivity, etc.)
I belong to Tendermint Infrastructure Security Team, and 3 cosmos sdk backend developers and 1 front engineer are in Tendermint. The CEO of Beharvest is Tendermintβs Head of DeFi.
We have a good understanding of Tendermint and are closely tied to Tendermint-based PoS chains.
In addition, there are 4 full-time experts in devops, and they have a lot of experience including penetration testing of major Korean banks and building IBM internal infrastructure.
Security
I think the most important validator key should be secured by HSM to IDC. We have experience with HSM. But I donβt think there is a perfect trust in HSM software (TM-KMS). Therefore, we pursue a perfect network separation method rather than hardware key security. (Of course, it is safer to apply both)
Currently, we have an agreement with KINX, which has the only Amazon IDC DX in Korea, and own the network space in a completely separate environment. Therefore, we operate the validator nodes in a secure hardware environment. In some cases, we use cloud HSM, and if there is a KMS recommended by the foundation, we use the software together with Ubikey.
Reliability
We have a highly available IDC and redundancy to the cloud through multi-cloud. It is also operated in a three-level sentry structure within the cloud. Nodes are monitored in real time with Pager Duty, Grafana, Prometheus, etc., and at least 5 employees are on standby, so the response is fast and accurate. We have our own professional operating process, which is very robust and highly reliable.
Currently, we are producing a multiverse as an internal project of the company. Multiverse is an integrated tool that enables integrated operation of all nodes, such as monitoring and operation status, upgrade automation, and automatic reward withdrawal, and is expected to enable more robust operation when completed. If we join Vega, we will make this software open source and contribute to the Vega ecosystem.
Performance
Achieving liveness and safety at the same time is a challenging task. However, if the environment is focused on network availability, liveness can be optimized while maintaining a certain level of safety. By separating the network, we have the safety of the validator node and at the same time access the cloud environment through the DX connection. So, the liveness of the cloud is guaranteed at the same time as safety. However, due to the nature of the decentralized network, local decentralization is necessary. If nodes are concentrated only in an area with good liveness, if any network error occurs in that area, the entire network goes down. This is very detrimental to the network. Therefore, although performance is important, we are actively supporting regional decentralization at the expense of some performance.
Node Operating Specifications
-Cloud environment
For Amazon instances, we are using c5.2xlarge or c5.xlarge.
In the case of GCP, we are flexibly adjusting with kube.
-IDC We are using 1gb AWS DX line for full rack. Robustness is increased through circuit redundancy.
For Sentry, we are using server specs of 44core 64gb ram or higher. In the case of validator, a rack server of 8 core 16gb or more is used as a single instance in an independent environment.
Communication
We have our own Telegram for delegators and the largest SNS(kakaoTalk) chat room used by over 40 million Koreans. This allows us to communicate very actively. Also, internal contact mail exists. In the meantime, we have communicated a lot through these channels. We support by running a Cosmos Korea Telegram room and YouTube channel, and sometimes open a clubhouse to communicate with the community.
telegram: Telegram: Contact @b_harvest
mail : contact@bharvest.io
telegram: Telegram: Contact @Cosmos_Korea
kakaotalk: KakaoTalk Open Chat
youtube: Carl Tube - YouTube
clubhouse: μ½μΈνμ°μ€ - Clubhouse
Governance
For global delegators, we always represent the community and require a lot of communication from the foundation and validators. We constantly collect important issues and things that can be improved, and we make proposals and actually go through governance. Within the Cosmos Hub, significant governance was led/progressed about 5 times or more by us. We have a lot of conversations with the participants in the governance group, and we frequently discuss technical and economic issues with the Korean community we have.