死磕以太坊原始碼分析之Ethash共識演算法

mindcarver發表於2020-12-18

原始碼演算法

死磕以太坊原始碼分析之Ethash共識演算法

程式碼分支：https://github.com/ethereum/go-ethereum/tree/v1.9.9

引言

目前以太坊中有兩個共識演算法的實現：clique和ethash。而ethash是目前以太坊主網（Homestead版本）的POW共識演算法。

目錄結構

ethash模組位於以太坊專案目錄下的consensus/ethash目錄下。

algorithm.go
實現了Dagger-Hashimoto演算法的所有功能，比如生成cache和dataset、根據Header和Nonce計算挖礦雜湊等。
api.go
實現了供RPC使用的api方法。
consensus.go
實現了以太坊共識介面的部分方法，包括Verify系列方法（VerifyHeader、VerifySeal等）、Prepare和Finalize、CalcDifficulty、Author、SealHash。
ethash.go
實現了cache結構體和dataset結構體及它們各自的方法、MakeCache/MakeDataset函式、Ethash物件的New函式，和Ethash的內部方法。
sealer.go
實現了共識介面的Seal方法，和Ethash的內部方法mine。這些方法實現了ethash的挖礦功能。

Ethash 設計原理

Ethash設計目標

以太坊設計共識演算法時，期望達到三個目的：

抗ASIC性：為演算法建立專用硬體的優勢應儘可能小，讓普通計算機使用者也能使用CPU進行開採。
- 通過記憶體限制來抵制（ASIC使用礦機記憶體昂貴）
- 大量隨機讀取記憶體資料時計算速度就不僅僅受限於計算單元，更受限於記憶體的讀出速度。
輕客戶端可驗證性: 一個區塊應能被輕客戶端快速有效校驗。
礦工應該要求儲存完整的區塊鏈狀態。

雜湊資料集

ethash要計算雜湊，需要先有一塊資料集。這塊資料集較大，初始大小大約有1G，每隔 3 萬個區塊就會更新一次，且每次更新都會比之前變大8M左右。計算雜湊的資料來源就是從這塊資料集中來的；而決定使用資料集中的哪些資料進行雜湊計算的，才是header的資料和Nonce欄位。這部分是由Dagger演算法實現的。

Dagger

Dagger演算法是用來生成資料集Dataset的，核心的部分就是Dataset的生成方式和組織結構。

可以把Dataset想成多個item（dataItem）組成的陣列，每個item是64位元組的byte陣列（一條雜湊）。dataset的初始大小約為1G，每隔3萬個區塊（一個epoch區間）就會更新一次，且每次更新都會比之前變大8M左右。

Dataset的每個item是由一個快取塊（cache）生成的，快取塊也可以看做多個item（cacheItem）組成，快取塊佔用的記憶體要比dataset小得多，它的初始大小約為16M。同dataset類似，每隔 3 萬個區塊就會更新一次，且每次更新都會比之前變大128K左右。

生成一條dataItem的程是：從快取塊中“隨機”（這裡的“隨機”不是真的隨機數，而是指事前不能確定，但每次計算得到的都是一樣的值）選擇一個cacheItem進行計算，得的結果參與下次計算，這個過程會迴圈 256 次。

快取塊是由seed生成的，而seed的值與塊的高度有關。所以生成dataset的過程如下圖所示：

Dagger還有一個關鍵的地方，就是確定性。即同一個epoch內，每次計算出來的seed、快取、dataset都是相同的。否則對於同一個區塊，挖礦的人和驗證的人使用不同的dataset，就沒法進行驗證了。

Hashimoto演算法

是Thaddeus Dryja創造的。旨在通過IO限制來抵制礦機。在挖礦過程中，使記憶體讀取限制條件，由於記憶體裝置本身會比計算裝置更加便宜以及普遍，在記憶體升級優化方面，全世界的大公司也都投入巨大，以使記憶體能夠適應各種使用者場景，所以有了隨機訪問記憶體的概念RAM，因此,現有的記憶體可能會比較接近最優的評估演算法。Hashimoto演算法使用區塊鏈作為源資料，滿足了上面的 1 和 3 的要求。

它的作用就是使用區塊Header的雜湊和Nonce欄位、利用dataset資料，生成一個最終的雜湊值。

原始碼解析

生成雜湊資料集

generate函式位於ethash.go檔案中，主要是為了生成dataset,其中包擴以下內容。

生成cache size

cache size 主要某個特定塊編號的ethash驗證快取的大小 *， epochLength 為 30000，如果epoch 小於 2048，則從已知的epoch返回相應的cache size，否則重新計算epoch

cache的大小是線性增長的，size的值等於(2²⁴ + 2¹⁷ * epoch - 64)，用這個值除以 64 看結果是否是一個質數，如果不是，減去128 再重新計算，直到找到最大的質數為止。

csize := cacheSize(d.epoch*epochLength + 1)

func cacheSize(block uint64) uint64 {
	epoch := int(block / epochLength)
	if epoch < maxEpoch {
		return cacheSizes[epoch]
	}
	return calcCacheSize(epoch)
}

func calcCacheSize(epoch int) uint64 {
	size := cacheInitBytes + cacheGrowthBytes*uint64(epoch) - hashBytes
	for !new(big.Int).SetUint64(size / hashBytes).ProbablyPrime(1) { // Always accurate for n < 2^64
		size -= 2 * hashBytes
	}
	return size
}

生成dataset size

dataset Size 主要某個特定塊編號的ethash驗證快取的大小 , 類似上面生成cache size

dsize := datasetSize(d.epoch*epochLength + 1)

func datasetSize(block uint64) uint64 {
	epoch := int(block / epochLength)
	if epoch < maxEpoch {
		return datasetSizes[epoch]
	}
	return calcDatasetSize(epoch)
}

生成 seed 種子

seedHash是用於生成驗證快取和挖掘資料集的種子。長度為 32。

seed := seedHash(d.epoch*epochLength + 1)

func seedHash(block uint64) []byte {
	seed := make([]byte, 32)
	if block < epochLength {
		return seed
	}
	keccak256 := makeHasher(sha3.NewLegacyKeccak256())
	for i := 0; i < int(block/epochLength); i++ {
		keccak256(seed, seed)
	}
	return seed
}

生成cache

generateCache(cache, d.epoch, seed)

接下來分析generateCache的關鍵程式碼：

先了解一下hashBytes，在下面的計算中都是以此為單位，它的值為 64 ，相當於一個keccak512雜湊的長度,下文以item稱呼[hashBytes]byte。

①：初始化cache

此迴圈用來初始化cache：先將seed的雜湊填入cache的第一個item,隨後使用前一個item的雜湊，填充後一個item。

for offset := uint64(hashBytes); offset < size; offset += hashBytes {
		keccak512(cache[offset:], cache[offset-hashBytes:offset])
		atomic.AddUint32(&progress, 1)
	}

②：對cache中資料按規則做異或

為對於每一個item（srcOff），“隨機”選一個item（xorOff）與其進行異或運算；將運算結果的雜湊寫入dstOff中。這個運算邏輯將進行cacheRounds次。

兩個需要注意的地方：

一是srcOff是從尾部向頭部變化的，而dstOff是從頭部向尾部變化的。並且它倆是對應的，即當srcOff代表倒數第x個item時，dstOff則代表正數第x個item。
二是xorOff的選取。注意我們剛才的“隨機”是打了引號的。xorOff的值看似隨機，因為在給出seed之前，你無法知道xorOff的值是多少；但一旦seed的值確定了，那麼每一次xorOff的值都是確定的。而seed的值是由區塊的高度決定的。這也是同一個epoch內總是能得到相同cache資料的原因。

for i := 0; i < cacheRounds; i++ {
		for j := 0; j < rows; j++ {
			var (
				srcOff = ((j - 1 + rows) % rows) * hashBytes
				dstOff = j * hashBytes
				xorOff = (binary.LittleEndian.Uint32(cache[dstOff:]) % uint32(rows)) * hashBytes
			)
			bitutil.XORBytes(temp, cache[srcOff:srcOff+hashBytes], cache[xorOff:xorOff+hashBytes])
			keccak512(cache[dstOff:], temp)

			atomic.AddUint32(&progress, 1)
		}
	}

生成dataset

dataset大小的計算和cache類似，量級不同：2³⁰ + 2²³ * epoch - 128，然後每次減256尋找最大質數。

生成資料是一個迴圈，每次生成64個位元組，主要的函式是generateDatasetItem：

generateDatasetItem的資料來源就是cache資料，而最終的dataset值會儲存在mix變數中。整個過程也是由多個迴圈構成。

①：初始化mix變數

根據cache值對mix變數進行初始化。其中hashWords代表的是一個hash裡有多少個word值：一個hash的長度為hashBytes即64位元組，一個word（uint32型別）的長度為 4 位元組，因此hashWords值為 16。選取cache中的哪一項資料是由引數index和i變數決定的。

	mix := make([]byte, hashBytes)
	binary.LittleEndian.PutUint32(mix, cache[(index%rows)*hashWords]^index)
	for i := 1; i < hashWords; i++ {
		binary.LittleEndian.PutUint32(mix[i*4:], cache[(index%rows)*hashWords+uint32(i)])
	}
	keccak512(mix, mix)

②：將mix轉換成[]uint32型別

intMix := make([]uint32, hashWords)
	for i := 0; i < len(intMix); i++ {
		intMix[i] = binary.LittleEndian.Uint32(mix[i*4:])
	}

③：將cache資料聚合進intmix

for i := uint32(0); i < datasetParents; i++ {
		parent := fnv(index^i, intMix[i%16]) % rows
		fnvHash(intMix, cache[parent*hashWords:])
	}

FNV雜湊演算法，是一種不需要使用金鑰的雜湊演算法。

這個演算法很簡單：a乘以FNV質數0x01000193，然後再和b異或。

首先用這個演算法算出一個索引值，利用這個索引從cache中選出一個值（data），然後對mix中的每個位元組都計算一次FNV，得到最終的雜湊值。

func fnv(a, b uint32) uint32 {
    return a*0x01000193 ^ b
}
func fnvHash(mix []uint32, data []uint32) {
    for i := 0; i < len(mix); i++ {
        mix[i] = mix[i]*0x01000193 ^ data[i]
    }
}

④：將intMix又恢復成mix並計算mix的雜湊返回

for i, val := range intMix {
		binary.LittleEndian.PutUint32(mix[i*4:], val)
	}
	keccak512(mix, mix)
	return mix

generateCache和generateDataset是實現Dagger演算法的核心函式，到此整個生成雜湊資料集的的過程結束。

共識引擎核心函式

程式碼位於consensus.go

①：Author

// 返回coinbase, coinbase是打包第一筆交易的礦工的地址
func (ethash *Ethash) Author(header *types.Header) (common.Address, error) {
	return header.Coinbase, nil
}

②：VerifyHeader

主要有兩步檢查，第一步檢查header是否已知或者是未知的祖先，第二步是ethash的檢查：

2.1 header.Extra 不能超過32位元組

if uint64(len(header.Extra)) > params.MaximumExtraDataSize {  // 不超過32位元組
		return fmt.Errorf("extra-data too long: %d > %d", len(header.Extra), params.MaximumExtraDataSize)
	}

2.2 時間戳不能超過15秒，15秒以後的就被認定為未來的塊

if !uncle {
		if header.Time > uint64(time.Now().Add(allowedFutureBlockTime).Unix()) {
			return consensus.ErrFutureBlock
		}
	}

2.3 當前header的時間戳小於父塊的

if header.Time <= parent.Time { // 當前header的時間小於等於父塊的
		return errZeroBlockTime
	}

2.4 根據時間戳和父塊的難度來驗證塊的難度

expected := ethash.CalcDifficulty(chain, header.Time, parent)
	if expected.Cmp(header.Difficulty) != 0 {
		return fmt.Errorf("invalid difficulty: have %v, want %v", header.Difficulty, expected)
	}

2.5驗證gas limit小於2⁶³ -1

cap := uint64(0x7fffffffffffffff)
	if header.GasLimit > cap {
		return fmt.Errorf("invalid gasLimit: have %v, max %v", header.GasLimit, cap)
	}

2.6 確認gasUsed為<= gasLimit

if header.GasUsed > header.GasLimit {
		return fmt.Errorf("invalid gasUsed: have %d, gasLimit %d", header.GasUsed, header.GasLimit)
	}

2.7 驗證塊號是父塊加1

if diff := new(big.Int).Sub(header.Number, parent.Number); diff.Cmp(big.NewInt(1)) != 0 {
		return consensus.ErrInvalidNumber
	}

2.8檢查給定的塊是否滿足pow難度要求

if seal {
		if err := ethash.VerifySeal(chain, header); err != nil {
			return err
		}
	}

③：VerifyUncles

3.1叔叔塊最多兩個

if len(block.Uncles()) > maxUncles {
		return errTooManyUncles
	}

3.2收集叔叔塊和祖先塊

number, parent := block.NumberU64()-1, block.ParentHash()
	for i := 0; i < 7; i++ {
		ancestor := chain.GetBlock(parent, number)
		if ancestor == nil {
			break
		}
		ancestors[ancestor.Hash()] = ancestor.Header()
		for _, uncle := range ancestor.Uncles() {
			uncles.Add(uncle.Hash())
		}
		parent, number = ancestor.ParentHash(), number-1
	}
	ancestors[block.Hash()] = block.Header()
	uncles.Add(block.Hash())

3.3 確保叔塊只被獎勵一次且叔塊有個有效的祖先

for _, uncle := range block.Uncles() {
		// Make sure every uncle is rewarded only once
		hash := uncle.Hash()
		if uncles.Contains(hash) {
			return errDuplicateUncle
		}
		uncles.Add(hash)

		// Make sure the uncle has a valid ancestry
		if ancestors[hash] != nil {
			return errUncleIsAncestor
		}
		if ancestors[uncle.ParentHash] == nil || uncle.ParentHash == block.ParentHash() {
			return errDanglingUncle
		}
		if err := ethash.verifyHeader(chain, uncle, ancestors[uncle.ParentHash], true, true); err != nil {
			return err
		}

④：Prepare

初始化header的Difficulty欄位

parent := chain.GetHeader(header.ParentHash, header.Number.Uint64()-1)
	if parent == nil {
		return consensus.ErrUnknownAncestor
	}
	header.Difficulty = ethash.CalcDifficulty(chain, header.Time, parent)
	return nil

⑤：Finalize會執行交易後的所有狀態修改（例如，區塊獎勵），但不會組裝該區塊。

5.1累積任何塊和叔塊的獎勵

accumulateRewards(chain.Config(), state, header, uncles)

5.2計算狀態樹的根雜湊並提交到header

header.Root = state.IntermediateRoot(chain.Config().IsEIP158(header.Number))

⑥：FinalizeAndAssemble 執行任何交易後狀態修改（例如，塊獎勵），並組裝最終塊。

func (ethash *Ethash) FinalizeAndAssemble(chain consensus.ChainReader, header *types.Header, state *state.StateDB, txs []*types.Transaction, uncles []*types.Header, receipts []*types.Receipt) (*types.Block, error) {
	accumulateRewards(chain.Config(), state, header, uncles)
	header.Root = state.IntermediateRoot(chain.Config().IsEIP158(header.Number))
	return types.NewBlock(header, txs, uncles, receipts), nil
}

很明顯就是比Finalize多了 types.NewBlock

⑦：SealHash返回在seal之前塊的雜湊（會跟seal之後的塊雜湊不同）

func (ethash *Ethash) SealHash(header *types.Header) (hash common.Hash) {
	hasher := sha3.NewLegacyKeccak256()

	rlp.Encode(hasher, []interface{}{
		header.ParentHash,
		header.UncleHash,
		header.Coinbase,
		header.Root,
		header.TxHash,
		header.ReceiptHash,
		header.Bloom,
		header.Difficulty,
		header.Number,
		header.GasLimit,
		header.GasUsed,
		header.Time,
		header.Extra,
	})
	hasher.Sum(hash[:0])
	return hash
}

⑧：Seal給定的輸入塊生成一個新的密封請求（挖礦），並將結果推送到給定的通道中。

注意，該方法將立即返回並將非同步傳送結果。根據共識演算法，可能還會返回多個結果。這部分會在下面的挖礦中具體分析，這裡跳過。

挖礦細節

大家在閱讀本文時有任何疑問均可留言給我，我一定會及時回覆。如果覺得寫得不錯可以關注最下方參考的 github專案，可以第一時間關注作者文章動態。

挖礦的核心介面定義：

Seal(chain ChainReader, block *types.Block, results chan<- *types.Block, stop <-chan struct{}) error

進入到seal函式：

①：如果執行錯誤的POW，直接返回空的nonce和MixDigest，同時塊也是空塊。

if ethash.config.PowMode == ModeFake || ethash.config.PowMode == ModeFullFake {
		header := block.Header()
		header.Nonce, header.MixDigest = types.BlockNonce{}, common.Hash{}
		select {
		case results <- block.WithSeal(header):
		default:
			ethash.config.Log.Warn("Sealing result is not read by miner", "mode", "fake", "sealhash", ethash.SealHash(block.Header()))
		}
		return nil
	}

②：共享pow的話，則轉到它的共享物件執行Seal操作

if ethash.shared != nil {
		return ethash.shared.Seal(chain, block, results, stop)
	}

③：獲取種子源，並根據其生成ethash需要的種子

f ethash.rand == nil {
		// 獲得種子
		seed, err := crand.Int(crand.Reader, big.NewInt(math.MaxInt64))
		if err != nil {
			ethash.lock.Unlock()
			return err
		}
		ethash.rand = rand.New(rand.NewSource(seed.Int64())) // 給rand賦值
	}

④：挖礦的核心工作交給mine

for i := 0; i < threads; i++ {
		pend.Add(1)
		go func(id int, nonce uint64) {
			defer pend.Done()
			ethash.mine(block, id, nonce, abort, locals) // 真正執行挖礦的動作
		}(i, uint64(ethash.rand.Int63()))
	}

⑤：處理挖礦的結果

外部意外中止，停止所有挖礦執行緒
其中一個執行緒挖到正確塊，中止其他所有執行緒
ethash物件發生改變，停止當前所有操作，重啟當前方法

go func() {
		var result *types.Block
		select {
		case <-stop:
			close(abort)
		case result = <-locals:
			select {
			case results <- result: //其中一個執行緒挖到正確塊，中止其他所有執行緒
			default:
				ethash.config.Log.Warn("Sealing result is not read by miner", "mode", "local", "sealhash", ethash.SealHash(block.Header()))
			}
			close(abort)
		case <-ethash.update:
			close(abort)
			if err := ethash.Seal(chain, block, results, stop); err != nil {
				ethash.config.Log.Error("Failed to restart sealing after update", "err", err)
			}
		}

由上可以知道seal的核心工作是由mine函式完成的，重點介紹一下。

mine函式其實也比較簡單，它是真正的pow礦工，用來搜尋一個nonce值，nonce值開始於seed值，seed值是能最終產生正確的可匹配可驗證的區塊難度

①：從區塊頭中提取相關資料，放在全域性變數域中

var (
		header  = block.Header()
		hash    = ethash.SealHash(header).Bytes()
		target  = new(big.Int).Div(two256, header.Difficulty) // 這是用來驗證的target
		number  = header.Number.Uint64()
		dataset = ethash.dataset(number, false)
	)

②：開始產生隨機nonce，直到我們中止或找到一個好的nonce

var (
		attempts = int64(0)
		nonce    = seed
	)

③：聚集完整的dataset資料，為特定的header和nonce產生最終雜湊值

func hashimotoFull(dataset []uint32, hash []byte, nonce uint64) ([]byte, []byte) {
  //定義一個lookup函式，用於在資料集中查詢資料
	lookup := func(index uint32) []uint32 {
		offset := index * hashWords //hashWords是上面定義的常量值= 16
		return dataset[offset : offset+hashWords]
	}
	return hashimoto(hash, nonce, uint64(len(dataset))*4, lookup)
}

可以發現實際上hashimotoFull函式做的工作就是將原始資料集進行了讀取分割，然後傳給hashimoto函式。接下來重點分析hashimoto函式：

3.1根據seed獲取區塊頭

	rows := uint32(size / mixBytes) ①
	seed := make([]byte, 40) ②
	copy(seed, hash) ③
	binary.LittleEndian.PutUint64(seed[32:], nonce)④
	seed = crypto.Keccak512(seed)⑤
	seedHead := binary.LittleEndian.Uint32(seed)⑥

計算資料集的行數
合併header+nonce到一個 40 位元組的seed
將區塊頭的hash拷貝到seed中
將nonce值填入seed的後（40-32=8）位元組中去，（nonce本身就是uint64型別，是 64 位，對應 8 位元組大小），正好把hash和nonce完整的填滿了 40 位元組的 seed
Keccak512加密seed
從seed中獲取區塊頭

3.2 從複製的種子開始混合

mixBytes常量= 128，mix的長度為 32，元素為uint32，是 32位，對應為 4 位元組大小。所以mix總共大小為 4*32=128 位元組大小

mix := make([]uint32, mixBytes/4)
	for i := 0; i < len(mix); i++ {
		mix[i] = binary.LittleEndian.Uint32(seed[i%16*4:])
	}

3.3 混合隨機資料集節點

temp := make([]uint32, len(mix))//與mix結構相同，長度相同
	for i := 0; i < loopAccesses; i++ {
		parent := fnv(uint32(i)^seedHead, mix[i%len(mix)]) % rows
		for j := uint32(0); j < mixBytes/hashBytes; j++ {
			copy(temp[j*hashWords:], lookup(2*parent+j))
		}
		fnvHash(mix, temp)
	}

3.4 壓縮混合

for i := 0; i < len(mix); i += 4 {
		mix[i/4] = fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])
	}
	mix = mix[:len(mix)/4]

	digest := make([]byte, common.HashLength)
	for i, val := range mix {
		binary.LittleEndian.PutUint32(digest[i*4:], val)
	}
	return digest, crypto.Keccak256(append(seed, digest...))

最終返回的是digest和digest與seed的雜湊；而digest其實就是mix的[]byte形式。在前面Ethash.mine的程式碼中我們已經看到使用第二個返回值與target變數進行比較，以確定這是否是一個有效的雜湊值。

驗證pow

挖礦資訊的驗證有兩部分：

驗證Header.Difficulty是否正確
驗證Header.MixDigest和Header.Nonce是否正確

①：驗證Header.Difficulty的程式碼主要在Ethash.verifyHeader中：

func (ethash *Ethash) verifyHeader(chain consensus.ChainReader, header, parent *types.Header, uncle bool, seal bool) error {
  ......
  expected := ethash.CalcDifficulty(chain, header.Time.Uint64(), parent)

  if expected.Cmp(header.Difficulty) != 0 {
    return fmt.Errorf("invalid difficulty: have %v, want %v", header.Difficulty, expected)
  }
}

通過區塊高度和時間差作為引數來計算Difficulty值，然後與待驗證的區塊的Header.Difficulty欄位進行比較，如果相等則認為是正確的。

②：MixDigest和Nonce的驗證主要是在Header.verifySeal中：

驗證的方式:使用Header.Nonce和頭部雜湊通過hashimoto重新計算一遍MixDigest和result雜湊值,並且驗證的節點是不需要dataset資料的。

總結&參考

https://mindcarver.cn ☆☆☆

https://github.com/blockchainGuide ☆☆☆

https://eth.wiki/concepts/ethash/design-rationale

https://eth.wiki/concepts/ethash/dag

https://www.vijaypradeep.com/blog/2017-04-28-ethereums-memory-hardness-explained/

死磕以太坊原始碼分析之txpool
2020-12-25
原始碼
死磕以太坊原始碼分析之state
2021-01-13
原始碼
死磕以太坊原始碼分析之Kademlia演算法
2020-11-22
原始碼演算法
死磕以太坊原始碼分析之挖礦流程分析
2020-12-12
原始碼
死磕以太坊原始碼分析之MPT樹-上
2021-01-04
原始碼
死磕以太坊原始碼分析之rlpx協議
2020-11-24
原始碼協議
死磕以太坊原始碼分析之Fetcher同步
2020-12-03
原始碼
死磕以太坊原始碼分析之downloader同步
2020-12-23
原始碼
死磕以太坊原始碼分析之EVM指令集
2021-02-21
原始碼
死磕以太坊原始碼分析之區塊上鍊入庫
2020-12-24
原始碼
死磕 jdk原始碼之HashMap原始碼分析
2019-04-13
JDK原始碼HashMap
死磕以太坊原始碼分析之EVM如何呼叫ABI編碼的外部方法
2021-02-25
原始碼
死磕以太坊原始碼分析之p2p節點發現
2020-11-23
原始碼
死磕 java集合之ArrayList原始碼分析
2019-04-01
Java原始碼
死磕 java集合之HashMap原始碼分析
2019-04-01
JavaHashMap原始碼
死磕 java集合之CopyOnWriteArrayList原始碼分析
2019-04-01
Java原始碼
死磕 java集合之PriorityQueue原始碼分析
2019-04-20
Java原始碼
死磕 java集合之TreeSet原始碼分析
2019-04-16
Java原始碼
死磕 java集合之WeakHashMap原始碼分析
2019-04-13
JavaHashMap原始碼
死磕以太坊原始碼分析之EVM固定長度資料型別表示
2021-02-23
原始碼資料型別
死磕 java集合之LinkedHashMap原始碼分析
2019-04-01
JavaHashMap原始碼
死磕 java集合之LinkedList原始碼分析
2019-05-03
Java原始碼
死磕 java集合之ConcurrentHashMap原始碼分析（一）
2019-04-08
JavaHashMap原始碼
死磕 java集合之ConcurrentLinkedQueue原始碼分析
2019-04-27
Java原始碼
以太坊原始碼分析(11)eth目前的共識演算法pow的整理
2018-05-13
原始碼演算法
死磕 java併發包之AtomicInteger原始碼分析
2019-05-06
Java原始碼
死磕 java集合之TreeMap原始碼分析（四）-內含彩蛋
2019-04-04
Java原始碼
死磕 java併發包之LongAdder原始碼分析
2019-05-12
Java原始碼
死磕 java集合之ConcurrentSkipListMap原始碼分析——發現個bug
2019-04-14
Java原始碼
死磕 java集合之TreeMap原始碼分析（二）——紅黑樹全解析
2019-04-13
Java原始碼
死磕 java集合之TreeMap原始碼分析（三）——紅黑樹全解析
2019-04-13
Java原始碼
死磕 java集合之TreeMap原始碼分析（一）——紅黑樹全解析
2019-04-13
Java原始碼
死磕 java集合之TreeMap原始碼分析（四）——紅黑樹全解析
2019-04-13
Java原始碼
死磕 java集合之ConcurrentHashMap原始碼分析（二）——擴容全解析
2019-04-13
JavaHashMap原始碼
死磕 java集合之ConcurrentHashMap原始碼分析（一）——插入元素全解析
2019-04-13
JavaHashMap原始碼
死磕演算法之插入排序
2018-06-29
演算法排序
死磕演算法之氣泡排序
2018-06-29
演算法排序
死磕 java集合之TreeMap原始碼分析（二）- 內含紅黑樹分析全過程
2019-04-04
Java原始碼