[News] 이더리움 확장성과 채택 // Ethereum's scalabilty and adoption v1.0

Vitalik Buterin: Increasing Transaction Costs Risk Limiting Ethereum Adoption 

비탈릭 부테린: 트랜잭션 비용 증가는 이더리움 채택에 제한을 걸다

< 원문기사링크 https://www.coindesk.com/vitalik-buterin-increasing-transaction-costs-risk-limiting-ethereum-adoption >

□ Article contents(기사내용)

The increased cost of transacting on the ethereum blockchain is hurting the software’s adoption, says project creator Vitalik Buterin.
프로젝트 제작자 비탈릭 부테린은 이더리움 블록체인에서의 거래 비용이 증가하면서, 이 소프트웨어의 채택에 타격을 입히고 있다고 말한다.

Speaking with the Toronto Star this week, Buterin suggested projects that are considering whether to build on the technology will likely be butted out as the blockchain is overloaded with transactions, or in his words “almost full.”
(While a blockchain cannot ever be technically ‘full,’ Buterin’s comments indicate his current sentiment on the severity of the problem.)
부테린은 이번 주 토론토 스타와의 인터뷰에서, 이더리움 블록체인이 트랜잭션으로 꽉 차있거나 거의 꽉차있다는 이유로, 이더리움을 기반으로 구축할지 고려중인 프로젝트들은 존폐의 기로에 서게 될 수 있다고 말했다.
(블록체인은 기술적으로 꽉 찰수는 없지만 부테린의 발언은 문제의 심각성에 대한 그의 현재 감정을 보여준다.)

Still, Buterin’s comments speak to his understanding of the difficulties ahead for the project, with major planned upgrades including Ethereum 2.0 and a switch to proof-of-stake consensus ahead.
그러나 부테린의 발언은, 이더리움2.0을 포함한 계획된 주요 업그레이드와 향후 지분증명합의로 전환과 함께 이 프로젝트가 마주할 어려움을 반영하고 있다.

He told the newspaper:
“If you’re a bigger organization, the calculus is that if we join, it will not only be more full but we will be competing with everyone for transaction space. It’s already expensive and it will be even five times more expensive because of us. There is pressure keeping people from joining, but improvements in scalability can do a lot in improving that.”
그는 신문사의 인터뷰에서 이렇게 말했다.
"큰 기관이 들어올때, 그들은 이더리움 네트워크에 합류시 더 꽉 찰 뿐만 아니라 거래 공간을 놓고 모든 참여자들과 경쟁할거라고 생각할겁니다. 그렇지 않아도 이미 수수료가 높은데, 합류하면 우리때문에 심지어 5배 높을것이다. 이는 합류하는 것을 주저하게 만들고, 따라서 확장성 개선은 그런 문제 역시 개선시킬것이다.

Ethereum’s seven-day transaction fee average, a measure of demand on the network, actually sits at a 50-day low, falling since July 1 to sit around $0.11 ether per transaction currently.
이더리움의 주간 거래 수수료 평균은, 네트워크 수요의 척도로써, 실제로 7월 1일 이후 50일 동안 최저 수준으로, 현재 거래당 $0.11에 머물고 있다.
< Ethereum’s seven day mean transaction fee image via Coinmetrics
Coinmetrics를 통한 이더리움의 주간 평균 거래 수수료 이미지 >

Buterin, following past arguments and his current work, presented PoS as a potential solution to the problem, stating that altering transaction verification could lower fees by a factor of 100 per transaction, freeing space for organizations to build on the blockchain.
부테린은 과거의 주장과 그의 현재 작업에 이어, PoS를 잠재적인 해결책으로 제시하면서, 거래 검증을 변경하면 거래당 수수료를 100배까지 낮출 수 있으며, 집입 기관들이 블록체인에 구축할 공간을 확보할 수 있을거라고 말했다.

More broadly, the comments show how public adoption of ethereum is a growing concern. Earlier this month, the Enterprise Ethereum Alliance (EEA) appointed the Ethereum Foundation’s Aya Miyaguchi head of its Mainnet Initiative, a working group to connect enterprises with ethereum’s services.
넓게 보면, 그의 발언은 이더리움의 대중적 수용이 얼마나 큰 관심거리인지를 보여준다. 이달 초 이더리움기업연합(EEA)은 이더리움 재단의 미야구치 아야를 메인넷 이니셔티브 대표로 임명했다.

Discussing governance and adoption, Buterin said price volatility and cybersecurity remain leading issues as well. He concluded that the government has a role in regulating the space:
부테린은 거버넌스와 채택을 논의하면서, 가격 변동성과 사이버 보안도 여전히 중요한 이슈라고 말했다. 또한, 그는 정부가 공간을 규제하는데 큰 역할을 한다고 결론지었다.

“Governments do have a role and one of the roles in regulation. The usual concerns are about cryptocurrency exchanges where the basic idea is to do fundraising for a new project by directly selling tokens on the blockchains. There are debates whether specific kinds of ICOs [initial coin offerings] are legally categorized as securities.”
"정부의 역할 중 하나는 규제를 하는 것이며, 블록체인상에서 토큰을 직접 판매함으로써 새로운 프로젝트를 위해 자금조달을 하는 암호화폐 거래소에 대한 우려가 크다. ICO의 일부를 법적으로 증권으로 분류하는지에 대한 논란이 있다.

Buterin pointed toward low-risk uses of blockchain, such as identification of certifications, as adoption-leading technology.
아울러 부테린은 채택 선도 기술로써 인증 확인과 같은 위험부담 적은 블록체인 활용방안에 대해서도 언급했다.

□ Personal Comment(개인 논평)

 ㅇ깊어지는 이더리움 확장성 고민
    - 부테린 군이, 예전엔 단기 확장성 솔루션으로 영지식증명을 활용한다고 했다가 지난 7월에는 비트코인캐시 체인이나 이더리움 클래식 체인을 활용하자는 아이디어*를 낸걸 보고있자면, 이더리움 확장성 해소가 그만큼 시급하고 중요하다고 할것이다.
 ※ 관련글: https://ethresear.ch/t/bitcoin-cash-a-short-term-data-availability-layer-for-ethereum/5735
    - 여튼 기사내용 중, 부테린 군이 이더리움 체인이 현재 과부하 상태라 새로운 기관들이나 프로젝트들이 진입하기 어렵다고 지적하였고, 특히 이더리움 거래량이 거의 다 찼다고 말할정도로 현재 상황이 가볍지 않다는 뉘앙스를 풍겼다. 이 상황을 반전시킬수 있는 모멘텀은 아무래도 저 역시 최근 글들을 통해 강조한 '이더리움2.0'일것이다. 
    - 그런 관점에서 저 기사를 보며 필자는 2가지를 생각했다. 첫째로, (기사에서 PoS도입시 거래당 수수료가 100배 저렴해질거라고 했는데 왜 100배인지는 전 아직 모르겠지만) 유효성 검증과 투표, 그리고 거래처리속도가 왜 빨라지느냐에 대한 것이다. 우선 현재 이더리움 설계상으로는 벨리데이터(유효성 검증자)가 투표(검증자가 올바르다고 생각하는 블록에 메시징)마다 거래내역을 제출해야하기때문에 부하가 걸리고 결국 병목현상이 일상이 되는 등 체인의 확장성에 한계를 보여줬다. 그런데 이더리움2.0 설계상에서는 PoS메커니즘을 총괄하는 비콘체인 덕분에 EVM과 같은 실행머신이 없고(물론 eWasm이 대두되는 등의 이유도 있지만) 그런 머신을 사용하여 투표나 계산을 안해도 되니 그만큼 검증이 효율적이며 가스가 필요없게 된다. 뿐만아니라 일괄서명(aggregate signature)이라는 기법 덕분에, 모든 투표를 순서대로 긴시간동안 건건이 처리하지 않고, 심지어 오프체인상에서 충분히 모아질때, 즉 충분히 많은 검증자들이 지원하게될때(=스테이킹을 충분이 많이 하게될때), 체인에 전송 및 통합이 이뤄지고 이 과정을 보다 용이하게 만든다. 그덕에 비콘체인은 부하를 줄일수 있게 되고, 검증자들이 더 많이 참여하게 되며, 자연적으로 그만큼 탈중앙화되고 네트워크 보안도 올라가게 됩니다. 실제로 현재 이더리움 설계상에서는 벨리데이터 '참여'수가 최대 900정도에 불과하지만, 이더리움2.0설계에서는 그 '참여'수가 30만명도 커버가능하며, 시스템은 무려 최대 2^22(약 4백만)명까지 '지원'할수 있습니다. 이 2^22이라는 수치가 중요한 이유는 '시스템이 지원가능한 벨리데이터 수'가 클수록 '스테이킹할때 최소 이더수량'이 작아지기 때문이다. 가령 현재 이더 총 발행량이 2^27(약 1억 3천개, 실제론 1억 좀 넘음)이라하면 이더체인이 견딜수 있는 최대 오버헤드(초당 메시지)를 감안할때(이더측에서는 5천~6천정도 견딜수있을것으로 보고있음), 벨리데이터가 최대 2^22인데, '총 발행량/최대 벨리데이터'를 계산하면 2^5 즉 32ETH가 나오고 이게 바로 현재 계획상의 이더리움2.0에서 스테이킹할때 최소 이더수량이 나온다. 기사를 보며 생각한 두번째는, 이더리움 합의방식의 전환과 기관 진입입니다. 기사내용에서 부테린 군이 언급한 '기관 진입'이 '이더리움을 사용'할 기관 또는 프로젝트 추진 주체로 저 역시 해석했지만, 동시에 떠올린게 '이더를 매수'할 기관 또는 프로젝트 추진 주체였다. 제가 아는 소식통에 따르면 기관들이 이더매수에 다소 관망한다고 들었다. 왜 그런고 하니, 이더리움 행보가 투자하기에 애매하답니다. 확장성 해소도 문제지만, PoW에서 이더리움2.0에서의 PoW/PoS -> Full PoS까지 가는 여정이 너무 리스크가 크다는 것이다. 보통 여윳돈으로 코인에 투자하는 상대적으로 리버럴한 개인투자자들과는 달리, 우리가 생각하는 이상으로 보수 투자자들인 기관들은 '이더가 이더인건 알겠지만, 여튼 적극적일수는 없다'라는 것이다.
  - 항상은 아니지만, 유의미한 혁신은 변방에서 오기도 한다. 라이트 형제가 '사람을 날게하는 기이한 기구'라는 당시 획기적인 아이디어를 실행에 옮겼지만, 향후 수백명을 태울 보잉기나 레이더에 안 잡히는 스텔스를 생각하진 않았을겁니다. 마찬가지로, 부테린 등 이더리움 설립자들도 '월드컴퓨터'라는 현재로서는 원대한 컨셉을 잡긴했지만 어떻게 성공하거나 변질될지 모른다. 다만, 비행기가 다양한 기업들의 진입과 수많은 수요 덕분에 하나의 거대한 산업과 대중적 수용을 이룬것처럼, 이더리움도 체질개선 잘 하고 특이점만 넘으면 산업표준은 물론 인류사회의 한 페이지를 장식할수도 있다. 그런데 아직은 그 꿈의 궁전은 요원하고, 거길 가려고 해도 수많은 하드포크와 이더리움2.0이라는 큰 변곡점을 앞두고 있다.


법적 고지 : 본 게시글은, 투자를 위한 정보제공을 목적으로 작성되었기에 투자결정은 신중을 기하여 주시기 바라며, 참고자료를 토대로 본인 판단하에 내용을 추가, 편집 등 작성되었기에 본인의 허락없이 복사, 배포, 편집 등을 할 수 없습니다.

[Ethereum] '제68차 이더리움 개발자 회의' 분석 및 개인 논평(8월 16일) v1.0

#68 Devs Meeting Review(16 Aug 2019)

- Related link : https://github.com/ethereum/pm/issues/119



English version(한국어 버전은 하단에)

□ Roadmap(https://eips.ethereum.org/EIPS/eip-1679) 

   <Istanbul HF Roadmap>
     - May 17(Fri): hard deadline to accept proposals for “Istanbul”
     - July 19(Fri): soft deadline for major client implementations
     - Aug 14(Wed): projected date for testnet network upgrade(Ropsten, Gorli, or ad-hoc testnet) Delayed due to EIP implementation and testing
     - Mid-September(Not fixed): Testnet fork
     - Oct 8 to 11: DevCon5, Osaka Japan
     - Oct 16(Wed) Initial projected date for mainnet upgrade(“Istanbul”)

□ Related to the EIPs for Istanbul HF

  ㅇIstanbulHF client update for EIPs allowed
    - (Nethermind) We only got EIP-1344, but didn't have EIP-152, 1108, 2028, 1884, 2200.
    - (Geth) We got EIP-1344, 1108, 2028, 1884, but didn't have EIP-152, 2200.
      * Other clients are absent.

  ㅇDecision about tentative EIPs
    - EIP-2200 and EIP-1884 will be included to Istanbul HF as they are judged to have reached an agreement without disagreement.

□ Conformance testing

  ㅇSpace for testing, Gitter channel and ReTestEth
    - EIPs to be included in HF must be tested, and the tests should be performed by EIP proposer or champion. However, sometimes proposers or champions are too motivated to know how to test what kind of test is required and in this case, other devs may suggest a way to facilitate the test. To do this, we will be able to test it through multiple clients on Gitter channel or ReTestEth.

□ Upgrading testnet and follow-up steps to Istanbul HF

  ㅇSeptember 4(Wed) of testnet HF block number 
    - We have just decided on the EIPs to be included in Istanbul HF but Parity is not present at the meeting, so we cannot decide testnet HF block number, which will be determined at next meeting (or through Gitter).
    - All clients should be prepared to execute all EIPs to be included in Istanbul HF by August 23(Fri) when the next meeting will be held.

  ㅇIstanbul HF conducted twice.
    - We will do Istanbul HF twice because there are EIPs we want but can't include in Istanbul HF such as EIP-1057 (or ProgPoW), but are not yet ready.

□ HF at once or separately

  ㅇAt once
    - By placing the prepared EIPs in the pool and implementing multiple EIPs at once, the plan can be established at the expected time intervals and there are chances for controling the HF issues.  However, EIPs proposers may be in a hurry due to the HF review deadline.

  ㅇSeparately
    - When fully prepared, EIP can be proposed and individual HF can be done. However, it will be messy as a number of seperate HFs are needed.

  ㅇ Fundamental issue
    - It is important to do HF at once or seperately, but a more important thing is that not much consideration is made until EIPs are implemented for HF. In fact, no one monitors the EIPs and no one pays attention at the last check. Therefore, clients should accept the proposed EIPs from the beginning, but attend the meeting to assess their progress.
    - Another concern is that before someone proposes an EIP and builds, and executes it, clients seem to know whether it's good or bad.
    - The problem with the EIP process is that the overall process cannot be tracked, and to solve it, the EIP progress is visually expressed so that many parties can know when to look at the EIP. To monitor progress from a client perspective, it is also good to use a dashboard.
    - Everything just discussed seems reasonable, and we don't have to decide immediately how to do it, but we'll discuss it further.

□ Naming HF

  ㅇ After Istanbul HF
    - Naming the HF was an old debate that began in April, and was re-discussed after two rounds of Istanbul HF. Second Istanbul HF is called by a different name besides Istanbul HF 2.
    - The HF after Istanbul HF will be named after the city where Devcon was held(e.g., Istanbul HF 2 will be Berlin HF where Devcon 0 was held).

※ Istanbul HF decision issue

    < Confirmed EIPs > Included in Istanbul HF, October 2019.
     1) EIP-152 (former EIP-2024) : Introducing a pre-compiled cotracts for EVM that implements a new encryption hashing algorithm called BLAKE2b.
     2) EIP-1108 : Proposal for reducing gas cost of alt_bn128 pre-compile. Improving personal information protection and scalability by reevaluating expensive elliptical curve calculation pre-comfiles.
     3) EIP-1344 : Specifying chain ID(a means to prevent replay of transactions between different chains), adding opcodes to access the chain ID to check the validity of signatures, and preventing other interchain replay attacks.
     4) EIP-1884: Maximizing block gas limit and stabilizing processing time by balancing gas consumption and resource consumption.
     5) EIP-2028 : Reducing gas cost of Calldata(where transaction data is stored when transaction is requested on the chain). Reducing Calladata costs can create potentially larger blocks, which can increase network latency, but can also have incidental effects of increased network security and scalability due to mathematical modeling and empirical estimation.
     6) EIP-2200(EIP-1283 + EIP-1706): Changing the total gas metering to reduce new usability for smart contract storage and excessive gas consumption when most methods of operation are not in place. In addition, SSTORE is not allowed if gas cost is lower than call stipend.

    < Tentatively decided EIPs > Included in 2020 HF
     1) EIP-663: Currently, SWAP and DUP commands are limited to the depth of 16 on the stack, but and corresponding SWAPn and DUPn are allowed access to all depths of 1024 items thanks to this EIP.
     2) EIP-1057 : It is called ProgPoW and is modified to make the most of commercial GPU resources in order to reduce ASIC's improved efficiency.
     3) EIP-1380: Reducing gas cost for self-calls, and reducing gas cost for call instructions when running a new instance of the currently loaded contracts.
     4) EIP-1702: For generalized account version management, enabling multiple versions of EVM to execute in the same block to facilitate HF while maintaining the correct function of the existing account.
     5) EIP-1962: Proposal to the definition and combination of elliptical arithmetic and runtime, an extension to EIP-1829 and lower working costs than the STATICCAL opcode in EIP-1109.
     6) EIP-1985: Applying the appropriate limit range for EVM parameters such as gas limit and block number. Explicit scope makes it easy to implement compatible clients.
     7) EIP-2045:improving the speed without introducing a separate subroutine and without changing the method of jump operation by reducing gas cost of computational opcode gas cost to increase Ethereum transaction volume(scalability).
     8) EIP-2046: Making file usage more efficient by reducing the gas of static calls to pre-com files.

□ Personal Comments

  ㅇEthereum's rate of issuance and return
    - In a personal comment to the 67th Ethereum Devs meeting, I explained about Ethereum 2.0. If you are an Ether investor, perhaps the most interesting thing in Ethereum 2.0 is the conversion of consensus protocols from PoW to PoS, especially funding deposits, validation, or staking.
    - But there is a thing associated with this stake, which is the issue rate. You will all know that adjusting the supply of one asset changes its value(assuming that other factors such as demand, are the same). However, it must also be known that network security and liquidity are very much related to such supply and value.
    - In order to learn more about these Ether monetary policies, we will look at the trend of Ether's issuance through photos below.
< the trend of ether issuance(orange) & volume(blue)(https://medium.com/ethhub) > 
  - Ether has shown rapid fluctuations in the issuance rate of major events such as difficulty bombs, major HFs, and the phase 2 of ethereum2.0(shard-chain). Such a trend in the rate of issuance is increasingly declining, and the total volume of issuance is rounded to a smooth curve. The most ideal aspect of the Ethereum network here would be the network's security with a lower issuance rate. However, if the issuance rate is to be low, there must be fewer validators to increase network security.
< ether issuance & staking rate in Ethereum2.0(https://docs.ethhub) >
    - In the picture above, a security risk is large because the lower the number of staked ether used for validation, the smaller the issuance rate, but the higher the chances that a few whales will control the network.
    - Of course, all of these analyses do not take into account the following variables: The first variable is the price of ether. As you know, the price volatility of cryptocurrency is very big, which can have a significant impact on the price-based staking rate. The second variable is the 'architectural factor of Ethereum 2.0. To date, it has been found that it is not possible to transfer ether between the chain and the existing PoW chain until phase 2(2020) of Ethereum2.0. In other words, when beconchain is introduced and validation is initiated in early 2020, if you migrate to a new version of ether and then stake it, the staked ether cannot be moved to the exchange or cashed until the shard-to-shade transmission is available in 2021(as is now known, you can transfer another validator). The third variable is "investment sentiment", which is a more fundamental variable than the aforementioned first and second variables and is about whether ether investors hold Ether. In other words, if ether's investment is strong, investors will not only hold but also stake ether, and if it is not strong, they will sell or invest in other coins.
    - I've talked about it in a complicated way, but it's simple. Keep an eye on ethereum, study and invest. To give you a simple hint for that, Devcon5 and IstanbulHF in October, Ethereum 2.0 Phase 0 and another HF in early 2020 are coming. What if ether is listed on BAKKT by the end of the year after Bitcoin?
   - But it's not only wishful thinking that these big events will bring about ether to the moon, but also keep in mind that each time it comes with enormous risks. Still, if our lives consist of a block of "decisions at moments" and a chain of "responsibilities for that decisions", I hope that your own blockchain will be a success project.


Disclaimer: Since this post was written for the purpose of providing information for investment, please be careful in your investment decision. You cannot copy, distribute, or edit the contents without my permission because it was made based on my own judgment based on the reference data.


한국어 버전

□ 로드맵(https://eips.ethereum.org/EIPS/eip-1679

   <이스탄불 HF 로드맵>
     - 05월 17일(금) : 이스탄불HF EIP 접수 확정기한
     - 07월 19일(금) : 주요 클라이언트 실행 마감기한
     - 09월 04일(수) 테스트넷에서의 네트워크 업그레이드*(Ropsten, Gorli, 또는 다른 임시 테스트넷)
      * 19.1월 비탈릭이 포크 대신 네트워크 업그레이드라고 부르고, 체인분기가 일어나는 경우만 하드포크라고 부르기를 이더리움 커뮤니티에 제안한 바 있음.
     -10월 16일(수) 메인넷에서의 네트워크 업그레이트(=이스탄불 HF)

□ 이스탄불HF 관련 EIP 관련

  ㅇ 이스탄불HF 허용(+잠정보류) EIP에 대한 클라이언트 업데이트
    - (Nethermind) 우리는 EIP-1344만 실행하였고, EIP-152, 1108, 2028, 1884, 2200은 아직 실행하지 않았습니다.
    - (Geth) EIP-1344, 1108, 2028, 1884를 실행하였고, EIP-152, 2200은 아직 실행하지 않았습니다.
      * 그 외 클라이언트는 불출석 등으로 언급이 되지 않았음

  ㅇ 잠정보류된 EIP에 대한 결정
    - EIP-2200과 EIP-1884은 이견없는 합의가 이루어졌다고 판단되므로 이스탄불HF에 허용될 예정이다.

□ 적합성 테스트

  ㅇ 테스트를 위한 공간, Gitter channel과 ReTestEth
    - HF에 포함될 EIP는 테스트가 반드시 행해져야하며, 그 테스트는 EIP제안자나 담당자가 수행하여야 한다. 다만, 제안자나 담당자가 의욕이 넘쳐도 어떤 테스트가 필요하는지 어떻게 그 테스트를 할수 있는지 모를때가 있는데, 이럴경우에는 다른 개발자들이 그 테스트를 용이하게 할 방법을 제시할수 있다. 이를 위해서 Gitter channel이나 ReTestEth와 같은 것을 통해 테스트를 하면 여러 클라이언트를 통해 테스트를 할수 있을것이다.

□ 테스트넷 업그레이드 및 이스탄불HF 후속 단계

  ㅇ 9월 4일(수) 테스트넷HF의 블록넘버 
    - 이제 막 이스탄불HF에 포함될 EIP를 정했고 Parity측이 회의에 참석하지 않은 관계로 우리는 테스트넷HF 블록넘버를 정할수 없으며, 그 블록넘버는 다음 개발자 회의에(또는 Gitter를 통해) 결정될것이다.
    - 이에 모든 클라이언트들은 다음 개발자 회의가 열리는 8월 23일(금)까지 이스탄불HF에 포함될 모든 EIP를 실행할수 있도록 준비하기를 바란다.

  ㅇ 이스탄불HF를 두번에 걸쳐 실시
    - 우리는 EIP-1057(또는 ProgPoW)와 같이 이스탄불HF에 포함시키고 싶지만 아직 준비가 되지 않은 EIP가 있기때문에 이스탄불HF를 부득이하게 두번에 걸쳐 실시할 예정이다.

□ HF를 모아서 할것인가 여러개로 나눠서 할것인가

  ㅇ 모아서 HF하기
    - HF가 준비된 EIP를 풀에 대기시켜 여러 EIP를 한번에 구현함으로써 예상가능한 시간간격대로 계획을 수립할수 있으며 HF와 관련된 사안들을 더욱 컨트롤할수 있는 여지가 있다. 다만 HF 검토 기한에 쫓겨 EIP담당자들이 다소 서두를수 있다.

  ㅇ 나눠서 HF하기
    - 충분히 준비가 되었을때 EIP를 제안하고 개별HF를 추진할수 있다. 다만, 수많은 개별HF를 추진해야하므로 그 과정에서 혼선이 발생할수 있다.

  ㅇ 근본적인 문제 
    - 모아서 또는 나눠서 HF를 하는것도 중요하지만, 더 중요한 문제는 EIP가 HF로 구현될때까지 많은 검토가 이루어지지 않는다는 점이다. 실제로 아무도 EIP를 모니터링하지 않으며 마지막 점검시 아무도 주의를 기울이지 않는다는 것이다. 따라서 클라이언트들은 초반부터 제안된EIP를 받아들이되 회의에 참석하여 그 EIP진행여부를 따져봐야한다.
    - 또다른 걱정거리는 누군가 EIP를 제안하고 그것에 대해 구축, 실행, 실행하기도 전에 클라이언트들로 하여금 그게 좋은건지 나쁜건지 파악해달라는 듯 하는 태도다.
    - EIP 프로세스의 문제점은 전체적인 프로세스를 추적할수 없다는 점이며, 그것을 타개하기 위하여 EIP진행상황을 시각적으로 표현하여 많은 당사자가 언제 EIP를 살펴봐야하는지 알수있게 하는 것이다. 클라이언트 관점에서 진행상황을 모니터링하기 위해서는 대시보드를 활용하는 것도 좋다.
    - 방금 논의된 것들은 모두 합리적으로 보이며, 어떻게 해야하는지 당장 결정할 필요는 없지만 더 논의하기로 한다.

□ HF 이름 짓기

  ㅇ 이스탄불HF 이후의 HF
    - HF 이름을 지어내는것은 지난 4월부터 시작된 오래된 토론 안건으로, 이스탄불HF가 두 차례에 걸쳐 실시되어 다시 논의하게 되었다. 2번째 이스탄불HF는 이스탄불HF 2 외에 다른 이름으로 불리는게 어떤가.
    - 이스탄불HF이후의 HF는 데브콘이 열린 도시의 이름을 따서 명명하기로 한다(가령 이스탄불HF 2는 데브콘0이 개최된 베를린HF로 하는식)


  ※ 이스탄불HF 결정 사안

    < 확정 EIPs > 2019년 10월 이스탄불HF에 반영 
     1) EIP-152(前 EIP-2024) : BLAKE2b라는 새로운 암호화 해싱 알고리듬을 구현하는 사전컴파일 컨트렉트를 EVM에 도입.
     2) EIP-1108 : alt_bn128 프리컴파일 가스비 절감제안. 값비싼 타원곡선산술 사전컴파일을 재평가하여 개인정보보호와 확장성을 개선.
     3) EIP-1344 : 컴파일링시 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)를 지정하고 opcode를 추가하여 그 체인ID에 접근하여 서명의 유효성을 검사하며, 다른 체인간 리플레이 어택 등을 방지.
     4) EIP-1884 : 가스소비와 자원소비 간 균형을 맟추어 블록가스제한을 극대화하고 처리시간이 안정화.
     5) EIP-2028 : Calldata(이더리움 상에서 트랜잭션 요청시 전송 데이터가 저장되는 곳)의 가스비를 현행보다 감소. Calladata비용이 절감되면 잠재적으로 더 큰 블록이 생겨 네트워크 지연이 증가하지만, 수학적 모델링과 경험적 추정에 의해 네트워크 보안이 강해지고 확장성이 증가되는 부수적인 효과가 있을수도 있음.
     6) EIP-2200(EIP-1283 + EIP-1706) : 총 가스 계량기(Net gas metering)를 변경하여 스마트컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 맞지 않을때 발생하는 과도한 가스비를 감소. 또한, 가스비가 집행비(Call stipend)보다 낮은경우 SSTORE사용을 불허함.

    < 잠정보류 EIPs > 2020년 차기HF에 반영
     1) EIP-663 : 현재 SWAP과 DUP명령어는 스택상 16의 깊이로 한정되어있는데, 이들과 대응되는 SWAPn과 DUPn을 1024개의 아이템의 모든 깊이까지 접근을 허용한다.
     2) EIP-1057 : ProgPoW로 불리며, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정.
     3) EIP-1380 : 자기호출에 대한 가스비 절감으로, 현재 로드된 컨트렌트의 새 인스턴스를 실행시 호출지시에 대한 가스비를 절감.
     4) EIP-1702 : 일반화된 계정버전 관리를 위한 것으로, EVM의 여러버전을 동일한 블록에서 실행할 수있게하여 기존 계정의 정확한 기능을 유지하면서도 HF를 용이하게 함.
     5) EIP-1962 : 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829에 대한 확장안이며 EIP-1109에서의 SATICCAL opcode보다 작업비용이 더 저렴.
     6) EIP-1985 : 가스제한, 블록넘버 등 EVM 매개변수들에 대한 적정 한계범위를 적용한다. 명시적인 범위를 적용하면 호환가능한 클라이언트를 구현하는데 용이함.
     7) EIP-2045 : 이더리움 거래량(확장성)을 높이기 위하여 Computational opcode의 가스비를 줄여서 별도의 서브루틴 도입없이 또 점프작동방식을 변경없이 속도를 향상함.
     8) EIP-2046 : 프리컴파일에 대한 정적호출의 가스비를 줄임으로서, 파일사용이 보다 효율적.


□ 개인 논평

  ㅇ 이더리움 발행률과 수익률
    - 지난 67차 이더리움 개발자 회의의 개인 논평에서 필자는 이더리움2.0에 대하여 설명하였다. 만약 당신이 이더 투자자라면 이더리움2.0에서 가장 관심있는 사안은 아마도 PoW에서 PoS로의 합의프로토콜 전환일것이고, 그중에서도 자금 예치 및 유효성 검증, 즉 스테이킹에 대한 관심이 클 것이다.
    - 그런데 이 스테이킹과 연관된 요인이 있으니 바로 '발행률'이다. 한 자산의 공급을 조절하면 (수요 등 다른 요인은 동일하다는 전제하에) 그에 따른 가치가 변한다는 것은 다 알것이다. 다만 네트워크에서는 그런 공급과 가치에 따라 네트워크 보안과 유동성에도 매우 큰 관련이 있다는 점도 반드시 알아야 한다.
    - 이러한 이더의 통화정책을 좀 더 알아보기위하여 이더의 발행 추이를 사진을 통해 알아보겠다.
< 이더 발행률(주황색)과 발행량(파랑색)의 추이(https://medium.com/ethhub) >

    - 이더는 난이도 폭탄, 주요HF, 이더리움2.0의 2단계(샤드체인도입) 등 굵직굵직한 이벤트마다 급격한 발행률 변동을 보이고 있다. 그런 발행률 추세는 점점 더 발행이 줄어드는 추세를 보이고 있으며, 그럴때마다 총 발행량은 원만한 곡선을 보이고 있다. 여기서 이더리움 네트워크의 가장 이상적인 모습은, 보다 낮은 발행률을 보이면서도 네트워크 보안성을 높은 상태일것이다. 그런데 발행률이 낮으려면 그만큼 유효성 검증자가 적어야하는데, 네트워크 보안성이 높아지려면 유효성 검증자가 많아야한다.

< 이더리움2.0에서의 이더발행과 스테이킹이율(https://docs.ethhub.io) >

    - 바로 위의 사진에서 보면, 유효성 검증에 활용되는, 즉 스테이킹된 이더가 적을수록 발행률은 작지만 소수의 고래들이 네트워크를 컨트롤할 확률이 높아지기에 보안리스크는 크다고 볼 수 있다.
    - 물론 이 모든 분석이 다음과 같은 변수들은 고려하지 않은 것이다. 첫째 변수는 '이더의 가격'이다. 아시다시피 암호화폐의 가격 변동성은 매우 큰 편으로 가격에 따른 스테이킹비율에도 적지 않은 영향이 있을수 있다. 둘째 변수는 '이더리움2.0의 구조적 요인'이다. 현재까지 밝혀진바로는, 이더리움2.0의 0단계(2020년 초)에서 2단계(2021년)까지는 체인안팎, 즉 기존PoW체인과 비콘체인 간 이더의 쌍방향 전송이 불가하다. 다시 말해, 2020년 초에 비콘체인이 도입되어 유효성 검증이 개시될때, 당신이 새로운 버전의 이더로 마이그레이션 후 스테이킹 할 경우 그 스테이킹한 이더는 2021년 샤드간 전송이 가능할때까지 거래소로 옮길수도 현금화 시킬수 없다(현재까지 알려진 바로는 다른 검증자에게 전송가능하다). 셋째 변수는 '투자자 심리'다. 앞서 말한 첫째, 둘째 변수보다 더욱 근본적인 변수로, 이더 투자자가 이더를 갖고있을것인가에 대한 사안이다. 즉, 이더의 투자성이 크다고 하면 홀딩은 물론 스테이킹까지 할것이며 투자성이 적다고 하면 이더 발행률과 수익률과는 무관한 현금화, 타 코인 투자 등을 선택할것이다.
    - 뭐 복잡하게 얘기했지만, 간단하다. 주시하고 공부하고 투자하라. 그것을 위하여 간단명료한 힌트를 드리자면, 10월에 있을 Devcon5이스탄불HF, 2020년 초에 있을 이더리움2.0 0단계또다른 HF가 우리를 기다리고 있다. 혹시 아나, 비트코인 다음으로 이더리움이 BAKKT에 연내 상장될지(이 글이 성지가 되길).
    - 하지만 이런 큰 이벤트들이 이더의 떡상을 부른다는 것은 희망사항일뿐, 그때마다 엄청난 리스크가 동반된다는 사실도 명심하길 바란다. 그럼에도, 우리의 인생이 '매순간의 결정이라는 블록''그 결정에 따른 책임이라는 체인'으로 구성되어있다고 한다면, 당신만의 그 '블록체인'이 꼭 성공하는 프로젝트가 되길 바라면서 이번 논평을 마치겠다.


법적 고지 : 본 게시글은, 투자를 위한 정보제공을 목적으로 작성되었기에 투자결정은 신중을 기하여 주시기 바라며, 참고자료를 토대로 본인 판단하에 내용을 추가, 편집 등 작성되었기에 본인의 허락없이 복사, 배포, 편집 등을 할 수 없습니다.


<Reference>
 1) https://medium.com/ethhub/the-basics-of-ethereum-2-0-economics-3bd2ffc7fd0e
 2) https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-economics

[Ravencoin] Ravencoin Devs Meeting(16 Aug 2019) // 8월 16일 레이븐 개발자 회의 분석 및 논평 v1.0

# Ravencoin Devs Meeting(16 Aug 2019)


(English) 한국어 버전은 아래쪽에 있음

□ Analysis of the meeting by subject

  ㅇ ASIC mining machine launch and how to beat ASIC mining
    - ASIC mining machine has been released and is already being sold through some sites. The machines on sale are as follows.

    - When changing Raven algorithm, devs discussed time frame from one week to eight weeks. And when deciding to change the algorithm, it will be mandatory change rather than community voting.
    - Tron Black(Tron) said the ASIC miners on sale are only 30% more efficient than GPUs, although they are cheap, and do not make a big difference (in terms of hash power and centralization) and therefore do not have a big threat. However, he said that the machines need a response. He also said he has an idea that will make GPU miners happy, and that a detailed change will be unveiled on Monday.
    - The existence of ASIC mining is against Raven's philosophy as stated in its White Paper, so devs will try to resist ASIC mining.
    - Tron said the proposed change would be small, and the so-called x16r2 would retain 16 sub-algorithms but could change rotation. However, he said that it would resist the current ASICs but not new ASICs. And this economics of the race is in our favor because of the cost of making ASICs that will be obsolete. The biggest risk is when mining hash power of less than 50 percent did not participate in the upgrade. For this reason, he said, we should make sure that almost everyone participates in the change.
    - Other devs expected to upgrade legit mining pools such as supernova, minermore, ravenminer, nanopool and beepool, and said it was very important for exchanges to join the upgrade.
    - Monero's introduction of CNv4, an ASIC resistance algorithm, is another option, but devs are now looking for lighter changes, Tron said. The reason is that CNv4 is CPU-friendly and its CPU mining will on the rise because botnets (which means malicious software that is planted to use the computer without the knowledge of the computer's owner) could be a problem.
    - When asked by a dev what to do to prevent ASIC, Tron said that we need to resist ASICs (with a small change) as we promised and schedule them so that we do not conflict with the introduction of restricted asset functions. He also said that if ASICs become more dominant, devs will focus more on the timing of the change and in that case, we should ensure that exchanges upgrade as well.
    - A dev said another Raven(Raven Classic) coin could come out if a hard fork activate. Another dev said that there is someone who owns a mining farm of 1GH at 800W. Changing the algorithm will reveal whether this is ASICs or GPUs.


□ Personal Comment

  ㅇ ASIC issues again
    - There was a heated discussion of ASIC resistance during dev meeting on July 19. Then, four weeks later, we have seen another devs' discussions on ASIC resistance again because of the ASIC miners sold to the public.
    - I will explain once again now that some people still don't know the importance and reason for ASIC resistance (this cannot be stressed enough). ASIC mining is an unacceptable issue for the Raven project, and it has already promised ASIC resistance through its white paper. If ASIC mining is left unattended, a small number of ASIC miners will monopolize the hash power and control the economy and the operation rights, which could result in catastrophic damage to network maintenance and security. In other words, the decentralization of authority would be collapsed.
    - The advent of ASIC miners means that the prelude to undermining the value of decoupling centrality that we must uphold has been raised. Some may question whether ASICs can be prevented in advance. It is theoretically yes, but it is practically impossible. It's like having a new disease or virus come out and then getting rid of it or a vaccine to weaken it.
    - Therefore, devs are forced to quickly change its algorithms before new ASICs are mass-produced whenever ASICs appear. In addition, the change must be made by miners and exchanges on time to maintain network security and manage liquidity. If Raven, which follows the existing chain, uses the same name as Raven Classic and engages with some exchanges, things get complicated.
    - The problem isn't over here. Raven devs are currently testing major features such as restricted assets and dividends to be on the mainnet, and it is also very important to activate them quickly. Thus, as Tron said, algorithm changes and activations of key functions should not conflict with each other or one should not be ignored because of the other.

  ㅇ We don't have the royal road but our own answer.
    - As mentioned repeatedly, if ASIC resistance is a matter of 'survival' for Raven, the development is a matter of 'well-being'. The Raven devs and community may have to play a seesaw game of 'survival' and 'well-being' in the long-term.
    - There are not one or two projects that have already been slashed by ASICs, and Ethereum and Monero are also struggling to resist ASICs.
    - The community's role in this game, which may be tough, is very important. As anyone knows, Raven is a special project. I won't explain why and what it is special here because it's already known in other writings, but it would be a very sad if this great project collapsed in the adversity of ASICs. Therefore, we need to concern and support it.
    - I dare say it, considering that most of you are Raven investors. We are probably the ones who discovered the value of Raven too early and then put our money into it. That's why some now in the red and may be emotionally watching Raven's price. However, based on the rational judgment of the time when you decided to invest, I hope you understand Raven's ASIC resistance and development as much as you invested. In the process, I hope devs will be guided so that they don't get lost by supporting what we think is right and criticizing what we think wrong.
    - In the end, when Raven's potential becomes a reality, I really hope that you get good return than you have invested in it.

(한국어) 

□ 소재별 회의 내용

  ㅇ ASIC 채굴기 출시와 그에 대한 대응책 모색
    - ASIC 채굴기가 이미 출시되었고 사이트를 통해 이미 판매되고 있다. 그 판매중인 채굴기들은 다음과 같다.
    - 레이븐 알고리듬 변경시, 변경주기를 어떻게 설정해야하는지에 대한 논의가 있었고, 짧게는 1주일부터 길게는 8주까지 다양했다. 그리고 알고리듬 변경을 위한 결정을 할때, 커뮤니티에 의한 투표나 의견수렴보다는 강제적인 시행이 옳다는 의견이 더 많았다.
    - 트론블랙(이하 '트론')은 현재 판매중인 ASIC 채굴기는 저렴하기는 하지만, GPU보다 30%정도 더 효율적이라고 말하면서, (해시파워, 중앙화 측면에서) 큰 차이를 일으키지 않으며 따라서 큰 위협은 아니라고 말했다. 다만, 그에 대한 대응은 필요하다고 했다. 아울러 그는 GPU채굴자들을 행복하게 할 아이디어가 있다면서, 월요일에 세부적인 알고리듬 변경안이 공개될거라고 말했다.
    - ASIC채굴이 존재한다는 것은, 레이븐 백서에 명시된 레이븐의 철학에 위배되는 것이며, 따라서 개발자들은 ASIC채굴을 저항하는데 노력할것이라고 말했다.
    - 트론은 제안된 알고리듬 변경은 작을것이며, 이른바 x16r2라고 불리는 이 알고리듬은 서브알고리듬을 16개로 유지하되 로테이션을 바꿀수도 있다고 말했다. 다만, 그것은 현재의 ASIC채굴기를 저항시킬뿐, 향후 새로운 ASIC채굴기를 막진 않을거라고 했다. 그리고 (변경된 알고리듬에 의해) 쓸모없어질 ASIC 채굴기의 제작 비용때문에 이 경제싸움은 우리가 유리하다고 말했다. 가장 큰 리스크는 50%이하의 채굴 해시파워가 알고리듬 변경 업그레이드에 동참하지 않았을 때다. 이런 이유로, 그는 우리는 거의 모든이들이 알고리듬 변경에 참여하는 것을 확실하게 해야한다고 말했다.
    - 이에 다른 개발자들은 supernova, minermore, ravenminer, nanopool, beepool 등과 같은 합법적인 채굴풀들은 업그레이드 할것이라고 예상하였고, 거래소들이 업그레이드에 동참하는게 매우 중요하다고 말했다.
    - 일전에 모네로의 ASIC 저항 알고리듬인 CNv4 도입 역시 하나의 선택지지만 현재로서는 좀더 가벼운 변경안을 모색중이라고 트론은 말했다. 그 이유는 CNv4는 CPU친화적이라 CPU채굴이 늘어날텐데 그 경우 봇넷(필자주 : 컴퓨터 주인 몰래 그 컴퓨터를 사용하기 위해 심는 악성 소프트웨어를 의미)이 문제가 될수 있기 때문이라고 말했다.
    - ASIC을 막기위해 무엇을 해야하는지 묻는 한 개발자의 질문에, 트론은 작은 알고리듬 변경을 통해 우리가 약속한대로 ASIC을 무기력하게 만들어야하고 제한자산 기능 도입과 충돌하지 않도록 일정을 짜야한다고 말했다. 또한, 만약 ASIC이 더욱 지배력이 높아지면, (알고리듬 변경) 시점에 대해 더욱 집중할것이며, 그 경우 거래소들 역시 업그레이드 하도록 확실히 해둬야 한다고 말했다.
    - 한 개발자는 알고리듬 변경을 위한 하드포크를 할경우, 또 다른 레이븐(레이븐 클래식) 코인이 나올수 있다고 말했다. 또다른 개발자는 현재 800W에 1GH를 뽐내는 채굴농장의 소유자가 있다면서, 알고리듬 변경시 이것이 ASIC채굴인지 GPU채굴인지 드러날것이라고 말했다.

□ 개인 논평

  ㅇ 또다시 불거진 ASIC 이슈
    - 지난 7월 19일 개발자 회의때 ASIC저항에 대한 열띤 논의가 있었다. 그러부터 4주가 지난 현재, 우리는 대중에게 판매되는 ASIC채굴기때문에 또한번 ASIC저항에 대한 개발자들의 논의를 목격하였다.
    - 여전히 ASIC저항의 중요성과 당위성에 대하여 잘 모르는 분들이 있을까봐 다시한번 설명해드리겠다(이는 아무리 강조해도 부족하지 않다). 레이븐 프로젝트에 있어 ASIC채굴은 허용될수 없는 사안으로, 이미 백서를 통해 ASIC저항을 약속했다. 만약 ASIC채굴을 방치한다면, 소수의 ASIC채굴자들이 해시파워를 독식하면서 그들에 의해 경제권과 운영권이 좌우될것이고, 이는 네트워크 유지 및 보안에 치명적인 손상이 가해질수 있다. 즉, '권한의 분산'이라는 탈중앙성의 가치가 무너지는 것이다.
    - 본문에서 언급한 채굴기의 등장은 우리가 반드시 지켜야할 탈중앙성의 가치를 훼손할 서막이 올라갔다는 의미다. 혹자는 ASIC을 미리 막을수 없냐고 의문을 가질수 있다. 이론상 가능하지만, 실제로는 거의 불가능하다. 이는 마치 새로운 질병이나 바이러스가 나타난 뒤에 비로소 그것을 없애거나 약화시키는 의술이나 백신이 나오는 것과 같다.
    - 따라서 개발자들은 ASIC이 나타날때마다 새로운 ASIC채굴기가 양산되기 전에 그때그때 재빠르게 알고리듬을 변경할수밖에 없다. 또한, 그 변경을 채굴자들과 거래소들이 제때 업그레이드를 하여 네트워크 보안 유지 및 유동성 관리를 해야한다는 점이다. 이때 기존 체인을 따르는 레이븐코인이 '레이븐 클래식'같은 이름을 달고 일부 거래소와 결탁을 한다면 일은 복잡해진다.
    - 문제는 여기서 끝이 아니다. 우리에겐 현재 제한자산, 배당 등과 같은 주요 기능들이 메인넷에 올려지도록 테스트중인데 이 기능을 빨리 활성화하는 것도 매우 중요하다. 따라서 트론이 말한것처럼, 알고리듬 변경과 주요 기능의 활성화가 상호 충돌하거나 어느 하나가 다른 하나때문에 묻혀지면 안된다.

  ㅇ 왕도는 없지만 그만의 정답은 있다
    - 누차 언급한대로, 레이븐에게 있어 ASIC저항이 '생존'의 문제라면 개발상황은 '웰빙'의 문제다. 레이븐 개발자와 커뮤니티는 앞으로 기나긴 '생존'과 '웰빙'의 시소게임을 해야할지도 모른다.
    - 이미 ASIC에 난도질 당한 프로젝트는 한두개가 아니며, 그 유명한 이더리움과 모네로 역시 ASIC저항 이슈는 합의가 잘 안되는 안건들 중 하나이다.
    - 험난할지도 모르는 이 게임에 있어 커뮤니티의 역할은 절대적이다. 아는 사람은 알겠지만 레이븐은 특별한 프로젝트다. 왜 그리고 무엇이 특별한지는 다른 글들을 통해 이미 알려져있으므로 여기서 굳이 언급하지 않겠지만, 이런 특별한 프로젝트가 ASIC이라는 역경에 무너진다면 매우 안타까운 사건이 될것이다. 따라서 우리 커뮤니티의 관심과 지지가 필요하다.
    - 필자의 글을 읽는 대부분이 레이븐 투자자임을 감안하여 감히 말씀드린다. 우리는 어쩌면 너무 일찍 레이븐의 가치를 발견하고, 거기에 본인 자산을 투입한 사람들일지도 모른다. 그 탓에 현재 손실권에 들어갔고 따라서 감정적으로 레이븐을 지켜볼지도 모른다. 하지만 현재의 부정적인 감정은 조금 내려놓고 투자하기로 결심했던 당시의 이성적 판단에 따라, 적어도 투자한 만큼 레이븐의 ASIC저항과 개발상황을 숙지하기를 바란다. 그런 과정에서, 옳다고 생각하는 것에는 지지를 옳지 않다고 생각하는 것에는 비판을 하여 개발자들이 길을 잃지 않도록 길잡이가 되어줬으면 좋겠다.
    - 마지막으로, 향후 레이븐의 잠재력이 현실화될때, 당신이 레이븐에 관심을 갖고 투자한 것 이상으로 수익을 내기를 진심으로 바라면서 이번 논평을 마치겠다.


법적 고지 : 본 게시글은, 투자를 위한 정보제공을 목적으로 작성되었기에 투자결정은 신중을 기하여 주시기 바라며, 참고자료를 토대로 본인 판단하에 내용을 추가, 편집 등 작성되었기에 본인의 허락없이 복사, 배포, 편집 등을 할 수 없습니다.

[Bitcoin] 비트코인의 흥망성쇠(3부작) 1부 "역대 주요이슈 분석" // Bitcoin's Rise & Fall(Trilogy) Part1 v1.5

비트코인의 흥망성쇠 (興亡盛衰) □ 에필로그   ㅇ 분석에 앞서     - 그동안 분석가로서 블록체인과 암호화폐가 지닌 기술 위주의 기본적 분석을 해왔으나, 투자자로서 유의미한 시세변동, 시세에 영향을 끼치는 이슈 등에 대한 분석글 작...