CoinNet and Transaction Replacement Updates

Dev. team Sprint 33 Update

Jan 14 · 7 min read
Image for post
Image for post

Functionality Implementations

Slashing Information Validation #1444 (Slashing Protocol, Feature)

This issue was related to issue #1076 which was about implementing the slashing protocol. We needed to split some tasks related to block header validation from issue #1076 because the tasks had many things to do and could consume some time.

We’ve been adding information about slashed validators into a block. The newly added information is as follows:

/// Hash of random seed of the preimages for this height

Hash random_seed;

/// List of indices to the validator UTXO set which have not revealed the preimage

uint[] missing_validators;

The ‘random_seed’ must not null in any case, which is generated from the preimages of current validators, and it must be the same as the local ‘random_seed’ from a node itself. In the current code of Agora, there are 2 cases when the information is not valid besides the case where a misbehaving validator manipulates the information. The following are the 2 cases:

  1. In the catch-up process, there are no pre-images for generating the local random seed needed for the comparison. So we need a process to get pre-images from other nodes and add the information into the ValidatorSet.
  2. In many unit tests or network tests, there are some cases that do not consider maintaining preimages needed for validation check and generating the random_seed.

Decouple TxBuilder from well-known KeyPair #1348 (Blockchain, Feature)

Image for post
Image for post

TxBuilder was originally created as a convenient way to create any kind of transaction in the test suite. However, it has proved good enough to be used as a general Transaction-building facility.

The design of this relies on the input being attributed to the well-known keypairs, it cannot yet be used outside of the testing mode. This should be fixed so that it both keeps the convenience it has in the test-suite but works with not-yet-known keypairs.

Set up alerts for restarting Agora #78 (Blochain Alerts, Feature)

This feature was so that an unscheduled restart would notify us. Scheduled restart should hopefully be automated (e.g. sending a message to #production).

Need stats for the current block height #1405 (Monitoring Tools, Enhancement)

Previously, we had stats such as agora_block_externalized_total. However, this was not very useful. It’s only counting how many new blocks were externalized since the last time the node booted up. So if the node restarts this count will go to zero. It’s much more useful to just show the actual current block height. That way if there are any discrepancies between the nodes we’ll be able to easily see them (and graph them).

TransactionPool should not filter double-spend transactions #1332 (Tx Replacement, Feature)

The current design of the TransactionPool prohibits the introduction of features such as:

  • replace by fee
  • transaction selection & filter mechanism #407

In the current design, if two transactions that spend the same UTXO are sent to the node, only one of the transactions will be accepted in the pool (the first one). That makes the transaction selection a race condition. And it also means the transaction pools across the nodes are in a conflicted state — it may affect consensus for example.

Of course, we also don’t want to blow up the size of the pool. A possible middle-ground would be to add the ability to group double-spend txs together. The pool could for example allow up to N transactions with the same UTXO, and later on, the transaction selection algorithm (#407) could pick the best candidate out of the double-spend set. When the block is externalized, all related tx’s spending that same utxo would be removed from the pool, and not just the tx’s that are in the block.

Add a timestamp to the block #1406 (Blockchain, Feature)

Our goal was for the Agora network to produce a block every 10 minutes. However, this cannot be a hard requirement as the nodes may fail to produce the blocks in case of network outages, or in case there is the inability to reach consensus in due time.

Due to this unpredictable nature of the block creation frequency, it’s not possible to accurately timestamp transactions based solely on the block height of the block in which a transaction was included.

A UTC unix timestamp should be added to the block. This field will be part of the hash and therefore signed.

Since we do not have miner nodes we need to use SCP to reach consensus on the timestamp which will be set in the block. This does create some problems we need to solve:

  • When should the timestamp be proposed? Should it be together with the ConsensusData? The problem here is that the total time it takes to reach consensus is unbounded, which means that by the time consensus is reached the proposed timestamp could already be quite old. Should the timestamp instead be proposed outside of ConsensusData in a separate round of voting after the transaction consensus has been reached? There is nothing preventing us from using SCP to vote on a separate proposal, so we might go with this approach. Voting on timestamps should be less contentious than voting on the transaction set.

Ongoing Development

  • Current Agora fails with Vibe.d errors #1432
  • Implement indirect payment channels via HTLCs #1419
  • Store the build information in the binary #1472
  • Slashing information validation #1444
  • Flash layer research & development #1266 (Ongoing)
  • Implement inbound connection banning support in vibe.d #202
  • Gain background knowledge of Smart Contracts #1463
  • Add requirements for “Transition” page to wallet #93

개발 스프린트 33 업데이트: 코인넷 및 트렌젝션 대체 업데이트

Functionality Implementations

#1444 슬래싱 정보 유효성 검사 (슬래싱 프로토콜, 기능)

이 기능은 슬레싱 프로토콜 구현에 관한 #1076과 관련이 있습니다. 블록 헤더 검증과 관련된 몇몇 작업은 수행해야할 작업이 많고 시간도 많이 필요해 #1076에서 분리했습니다.

절단된 검증자에 대한 정보를 블록에 추가하고 있습니다. 새로 추가된 정보는 다음과 같습니다.

/// 이 높이에 대한 사전 이미지의 임의 시드 해시

Hash random_seed;

/// 사전 이미지가 표시되지 않은 유효성 검사기 UTXO 집합에 대한 인덱스 목록

uint[] missing_validators;

‘random_seed’는 어떤 경우에도 null이 되어서는 안되며, 이는 현재 검증자의 사전 영상에서 생성되며 노드 자체의 로컬 ‘random_seed’와 동일해야 합니다. 현재의 아고라 코드에서는 잘못된 행동 확인자가 정보를 조작하는 경우 외에 정보가 유효하지 않은 경우가 2가지 있습니다. 해당 두 가지 경우는 다음과 같습니다.

  1. 추적 프로세스에는 비교에 필요한 로컬 랜덤 시드를 생성하기 위한 사전 영상이 없습니다. 따라서 다른 노드에서 사전 이미지를 가져와 정보를 검증자 집합에 추가하는 프로세스가 필요합니다.
  2. 수많은 단위 테스트 및 네트워크 테스트에서 유효성 검사를 살펴보면, random_seed 생성에 필요한 프리이미지 유지를 고려하지 않는 케이스들이 있습니다.

#1348 잘 알려진 KeyPair에서 TxBuilder 분리(블록체인, 기능)

Image for post
Image for post

TxBuilder는 원래 테스트 제품군에서 모든 종류의 트랜잭션을 편리하게 창조할 수 있는 방법으로 만들어졌습니다. 일반적인 트랜잭션 구축 시설로 사용될 만큼 충분히 좋다는 것이 입증되었습니다.

이 설계는 잘 알려진 키 페어로 귀속되는 입력에 의존하며, 아직 테스트 모드 외부에서 사용할 수 없습니다. 테스트 제품군의 편의성은 유지하지만 아직 알려지지 않은 키 페어와 함께 작동하도록 하며 이 문제를 해결해야 합니다.

#78 Agora를 다시 시작하기 위한 경고 설정(블록체인 경고, 기능)

이 기능은 예정에 없던 재시작을 알려주는 기능입니다. 이 기능의 개발 후 예약된 재시작에 대해 자동으로 알려줍니다. (예: #production으로 메시지 전송).

#1405 현재 블록 높이에 대한 통계 필요(모니터링 도구, 향상)

이전에는 agora_block_externalized_total과 같은 통계가 있었습니다. 하지만, 이는 마지막으로 노드를 부팅한 이후 외부화된 새 블록의 수만 계산하여, 노드가 다시 시작되면 수가 0이 되는 관계로 편리하지 않았습니다. 따라서, 현재 블록 높이를 표시하는 것이 훨씬 더 편리하며, 이 경우, 노드 간에 불일치가 있더라도 노드를 쉽게 볼 수 있고 그래프도 표시할 수 있습니다.

#1332 Transaction Pool은 이중 지출 트랜잭션를 필터링하지 않아야 합니다 (Tx 교체, 기능)

현재의 Transaction Pool 설계에서는 다음과 같은 기능을 도입할 수 없습니다.

  • 수수료로 대체
  • 트랜잭션 선택 및 필터 메커니즘 #407

현재 설계에서 동일한 UTXO를 사용하는 두 개의 트랜잭션이 노드에 전송되면 풀에서 한 개의 트랜잭션만 허용되는데 (첫 번째 UTXO), 이는 거래 선택을 경쟁적으로 만들고, 노드 전체의 트랜잭션 풀이 충돌 상태에 있다는 것을 의미합니다. 예를 들어, 합의에 영향을 줄 수 있습니다.

물론, pool의 크기를 부풀리면 안되기에, 이를 해결할 방안으로 이중 지출 tx를 함께 그룹화하는 기능을 추가할 수 있습니다. 예를 들어 풀은 동일한 UTXO로 최대 N개의 트랜잭션을 허용할 수 있으며, 나중에 트랜잭션 선택 알고리즘(#407)이 이중 지출 집합 중에서 가장 적합한 후보를 선택할 수 있습니다. 블록이 외부화되면 블록에 있는 tx뿐만 아니라 동일한 utxo와 관련된 모든 tx 지출이 풀에서 제거됩니다.

#1406 블록에 타임스탬프 추가(블록체인, 기능)

우리의 목표는 아고라 네트워크가 10분마다 블록을 생성하는 것이었습니다. 노드가 네트워크 중단 또는 적절한 시기에 합의에 도달할 수 없는 경우 블록 생성이 어려울 수 있으므로 이는 꼭 필요한 사항입니다.

블록 생성 빈도의 이러한 예측 불가능한 특성 때문에 트랜잭션이 포함된 블록의 높이만으로는 트랜잭션 타임스탬프를 정확하게 지정할 수 없습니다.

UTC unix 타임스탬프를 블록에 추가해야 합니다. 이 필드는 해시의 일부이므로 sign 됩니다.

우리는 Miner 노드가 없기 때문에 블록에서 설정될 타임스탬프에 대한 합의 도달을 위해 SCP를 사용해야 합니다. 이로 인해 해결해야 할 몇 가지 문제가 발생합니다:

‘타임스탬프는 언제 제안되어야 하나? 합의 데이터와 함께 사용해야 하는가?’
여기서 문제는 합의에 도달하는 데 걸리는 총 시간이 제한되지 않는다는 것이며, 이는 합의에 도달할 때까지 제안된 타임스탬프가 이미 오래되었을 수 있다는 것입니다.

‘대신, 거래 합의가 이루어진 후 별도의 투표에서 합의 데이터 외부에 타임스탬프를 제안해야 하는가?’
SCP를 사용한 별도의 제안을 투표하는 것을 막을 수 없으므로, 이 방법을 사용할 수도 있습니다. 타임스탬프에 대한 투표는 트랜잭션 집합에 대한 투표보다 덜 논쟁적이어야 합니다.

Ongoing Development

  • #1432 Vibe.d에러로 인한 최근 아고라 미작동
  • #1419 HTLCs를 통한 간접 지불 채널 구현
  • #1472 이진에서의 빌드 정보 저장
  • #1444 슬래싱 정보 확인
  • #1266 플래시 레이어 조사 및 개발 (진행중)
  • #202 vibe.d에서 인바운드 연결 금지 지원 구현
  • #1463 스마트 컨트렉의 배경 지식 획득
  • #93 “이전” 페이지에 대한 요구사항을 지갑에 추가

Please join our communication channels as follows!

Telegram Spanish:
Telegram Russian:
BOSAGORA Official Announcement:



Contribute to making a better world with blockchain…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store