關於 recursive c ，我們在網路上蒐集到這些相關的討論、資訊與評價

📜 [專欄新文章] Ethereum Casper — fork choice rule 之GHOST 與 RPJ
✍️ Kimi W
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

本篇在介紹Casper FFG POS鏈，鏈分叉的解決方法

在POW的世界中，就是比挖礦速度來決定最長鏈，那POS勒?! 怎麼解決分叉的問題？怎麼確認哪條分叉是有效的鏈？如果有一小群attackers ，假造了一堆block，變成最長的鏈，大家就傻傻的follow嗎?!

Casper FFG 一開始選用GHOST(Greedy Heaviest-Observed Sub-Tree) 作為選擇有效鏈的方式。GHOST原則上就是選總分最高的那條鏈當作有效鏈（在Casper FFG中，選擇最多人投票的鏈當作主鏈，而不是最長的當主鏈，所以這邊都是寫有效鏈，而不是最長鏈），下面是一個例子
來源：https://ethresear.ch/t/recursive-proximity-to-justific…/2561
最上面黃色的是最新被確認(finalized)的block，綠色的(I J)是鏈的head，每個區塊上的字母，代表簽章的人

C沒有被選擇，是因為B的簽章數比C多

F沒有被選擇，是因為(G H)的簽章數是5(G,H,I,J,M)，而F只有3(F,K,L)

(I J)簽章數是2，多於M(1個)，所以最後選定是 (I J) 這個區塊

GHOST選定有效鏈方式大概就這樣，還滿直覺的。

前幾週，基於GHOST選鏈的方式作了一些小修改，提出新的方式叫做RPJ（Recursive Proximity to Justification）。GHOST是票數多的當選，而RPJ是比最大值，也就是取每條分叉上的最大值，擁有最大值的那條鏈即為有效鏈。
來源：https://ethresear.ch/t/recursive-proximity-to-justific…/2561
以這個鏈為例，黃色分鏈最大值為51，綠色分鏈最大值為65，所以綠色鏈會被選為主鏈，就這樣（講完覺得有點空虛….XD）。為什麼會改用RPJ？這個方式的概念是，如果某個block被證明是合法的(justified)，這隱含了這個block的祖先們也被證明是合法的，所以一個區塊 justified 的機率會是其子孫區塊中最接近 justified 的機率（這邊感謝NIC Lin的糾正，下方會附上NIC LIN comment的原文）。

原文在這裡（英文不夠好，所以這裡附上原文）

The philosophy here is that if a block is justified, that implicitly justifies its ancestors as well, so the proximity of a block to being justified is really the minimum of the proximities of any of its descendants.

NIC Lin的commnet，直接引用原文

這邊原文寫錯了，是 maximum of the proximities of any of its descendants。 一個區塊 justified 隱含其區塊的祖先 justified 的意思，所以一個區塊 justified 的機率會是其子孫區塊中最接近 justified 的機率。

然而，這個方式也不是沒缺點，RPJ缺少了stability。以上面的例子來說，如果黃色的分鏈其他的validator繼續投票，有效分鏈就會變成黃色鏈了。不過Vitalik也提到，如果是在每個block都做justification，而不只是check point，就可以解決stability這個問題，不過這個提議或許還需要社群作討論才會有結論，就先知道就好。

reference:https://ethresear.ch/…/t/pos-fork-choice-rule-desidera…/2636

Originally published at kimiwublog.blogspot.com.

Ethereum Casper — fork choice rule 之GHOST 與 RPJ was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

Make 官方手冊...兼紀老師閒聊 Make 的優點

撰寫 Linux 程式多的人，應該或多或少都會接觸 Make 這套「流程自動化」軟體。它可以把一大堆像咒語一樣的 Linux 指令，給一個乾淨好記的名字，然後你就把那些又臭又長的指令忘了，直接執行那個好記的名字、放鬆喝杯茶，等著工作完成。

不過 Make 也有被人詬病的地方，就是它的自動化語法實在不太親民。由於它發明於 1977 年，當時用 Linux 的人，大多是些電腦專業學者，也不會在乎語法難不難（抑或說，越難越能激起這群人喜歡挑戰的劣根性？ XD）。不過一旦學會，它強大的功能實在讓人愛不釋手。我舉幾個我認為不錯的功能給大家：

(1) 目標相依（Target Dependency）：你可以要求乾淨好記名字背後那沱指令，執行前必須先執行另一沱定義於其它乾淨好記名字之下的指令。也就是說，你的 Make 會越寫越輕鬆，因為之前辛苦寫好的指令有機會被「重用（音『崇用』）」（咦？「重用」不就是「物件導向」的目的嗎？ XD）。如下所示：

my_command: other_command
（一堆像咒語一樣的 Linux 指令）

這會讓 my_command 所屬的那堆 Linux 指令執行前，先執行另一個名字 other_command 下所屬的那一沱 Linux 指令。

(2) 隱式規則（Implicit Rules）：你要求 Make 拿 abc.o （類似 Windows 內的 abc.obj）檔加入最終執行檔，但 abc.o 根本不存在。Make 會聰明到知道 abc.o 事實上是由 abc.c （C 語言原始碼檔）編譯過來的。在人類不必介入的情況下，它會聰明地自動編譯 .c 檔成 .o 檔，然後再執行所要求的指令。這會讓 Make 語法大大縮減。因為善用「潛規則」，可少寫很多行 Linux 指令。

(3) 遞迴建造（Recursive Build）：當你要求編譯如一串葡萄般複雜的子文件夾結構時，Make 若發現子文件夾內已經有 Make 指令檔了，它會全權委託該 Make 指令檔編譯當地文件夾的內容。這可以讓你撰寫「根 Make File 文件」時，適當分權各文件夾的 Make File 決定如何編譯當地文件。

(4) 與「環境變數」結合：Make 檔裡用的「變數」，根本就是 Linux 下的環境變數。也就是說，如果有個 Make 變數值是：

MY_VAR = abc

我臨時想把它改成 pqr，不必修改原始碼。只要在 Linux 命令列下執行修改「環境變數」的指令即可：

export MY_VAR = pqr

美妙的是，export MY_VAR = pqr 僅存於當下記憶體。下次重開機時，MY_VAR 又會變回 abc。很適合「臨時想改成一個值，但懶得下次改回來」的場合用。

不知不覺，這篇又變成「落落長」（台語，「冗長」之意）了。我寫這麼多，無非是希望我「嵌入式 Linux 程式設計班」的同學，除了詛咒 Make 語法怪異之餘，也能欣賞它的強大之處。「手排車」是比較難開，但要學「藤原拓海」做出過髮夾彎的「水溝蓋跑法」，麻煩您不要詛咒換檔時還要踩「庫拉幾（台語，「離合器」之意）」。

以下附上 Make 官方文件，我班上的同學，想下載 PDF 檔回去好好保存的...咳咳咳...我放在「秘密基地」裡的「eBook」資料夾...麻煩低調地搬回家觀賞... XD

http://www.gnu.org/software/make/manual/make.html

這裡有另一位國外網友，訴說他為何喜歡 Make 的原因。我大多贊同他的觀點，提供給各位參考：
http://bost.ocks.org/mike/make/