約瑟夫問題（Josephus Problem）

Thu, 29 Jun 2023 14:03:21 +0800

介紹

約瑟夫問題（Josephus Problem）是一個古老的數學問題，其名稱源自於猶太歷史學家弗拉維奧·約瑟夫斯（Flavius Josephus）。這個問題描述了一個關於生存和順序的遊戲。

問題的背景是這樣的：

假設有N個人（編號從1到N）站成一個圓圈狀。一開始，從第一個人開始按照順時針方向報數，報到第M個人就將其移出圈子，然後再從下一個人開始重新報數，如此重複，直到只剩下一個人為止。

問題的目標

目標是找到最後生存下來的那個人的編號**。
即，如果 N = 7，M = 3，那麼經過一輪報數和移除操作後，順序會變成3，6，2，7，5，1，最後剩下的是4號。

約瑟夫問題並不僅限於具體的數字，而是一個普遍的抽象問題，可以用數學方式來解決。

解決這個問題的一種經典方法是使用遞迴（recursion）。

基於遞迴的解法如下：

如果只有一個人（N=1），那麼他就是最後的生存者，回傳他的編號。
否則，從第一個人開始報數，並將每個第M個人移除。
移除完畢後，從下一個人開始重新遞迴調用這個過程（N-1個人）。
將遞迴返回的結果（即下一輪的最後生存者編號）調整到當前的編號對應的位置，然後回傳結果。

這樣，通過不斷遞迴和移除操作，最後得到的結果就是約瑟夫問題的解。

需要注意的是，

約瑟夫問題的解並不唯一，它取決於初始的 N 和 M 的值。
這個問題在數學和計算機科學中都有廣泛的應用，包括編程、遊戲理論等領域。

李永樂老師的講解

Youtube 影片

紀錄

先介紹了當k=2時的基本情況，然後討論了更一般的情況。

影片提供了遞推式來解決這個問題，將最後剩下的人表示為f(N, k)，其中N表示最初的人數，k表示每隔多少人殺一個。

他們的編號不同，例如原先的 4 號現在成了 1 號，原先的 5 號現在成了 2 號，原先的 6 號現在成了 3 號。
這意味著他們的編號相差3。
這個差值3正好對應到每隔幾人殺一個的k值。
因此，我們需要將這個差值加上k，這樣新的編號就會與原先的編號相同了。

影片解釋了遞推式的計算過程，並提到如果計算結果大於N，則需要減去N，相當於去取餘數。

最後給予一個範例呈現。
N = 8，總共 8 個人。
K = 3，每隔 3 個人殺一個。
最後生存者是 7 號。

流程圖

若想要清楚流程圖，大力推薦參考資料【Josephus Problem - GeeksforGeeks】

當 N = 5, K = 1 時候的流程圖。最後生存者是 3 號。

實作

// return the position of last man survives
function Josephus(n, k) {
    let i = 1;
    let ans = 0;
    while (i <= n) {

        // update the value of ans
        ans = (ans + k) % i;
        // 再進行下一個 i
        i++;
    }

    // 編號從 1 開始
    return ans + 1;
}

// This code is contributed by sarveshc111.

let n = 1; // 總人數
let k = 1; // 每次報數的數字
let lastSurvivor = Josephus(n, k);
console.log("最後生存者的編號是：", lastSurvivor);

最後，如果你覺得我的分享對你有幫助，請給予我一個愛心，並且分享這篇文章，這將是對我最大的鼓勵！

拜占庭問題 Byzantine Problem

Mon, 26 Jun 2023 17:12:26 +0800

拜占庭問題 Byzantine Problem

拜占庭問題源自電腦科學，尤其是分散式系統的領域。此問題是命名來自於拜占庭將軍的想像問題，這些將軍被敵人包圍，他們必須達成共識以確定下一步的行動：攻擊或撤退。他們的唯一通訊方式是通過傳遞消息，但問題在於，其中可能有叛徒傳遞假消息，導致非叛徒將軍無法達成共識。

在電腦科學中，這類似於一個分散式系統中的節點必須達成共識，即使有些節點可能故障或行為異常。這種情況可能會導致系統的一部分接受一種結果，而另一部分接受另一種結果，進而無法達成共識。

解決拜占庭問題的一種方法是使用拜占庭容錯（Byzantine Fault Tolerance, BFT）演算法。

BFT演算法旨在處理系統中的故障節點，以達到整個系統的共識。
最知名的BFT演算法是拜占庭將軍問題的原始解答 - 羅馬軍團演算法。

然而，這些算法通常需要多數的正常節點來達到共識，並且在節點數量大時效率降低。
因此，一種比較現代且廣泛使用的方法是使用區塊鏈技術，例如比特幣使用的工作量證明（Proof of Work, PoW）和以太坊等平台使用的權益證明（Proof of Stake, PoS）。這些協議能夠在大規模網路中達成共識，並且對抗拜占庭節點。

工作證明（Proof of Work，PoW）

工作證明（Proof of Work，PoW）是一種在區塊鏈技術中常用的共識機制。它的目的是確保在新增區塊到區塊鏈上時需要進行一定的計算工作，以驗證該區塊的有效性。Proof of Work 最早是由比特幣的白皮書提出，並成為許多其他加密貨幣所採用的共識機制。

在Proof of Work中，節點（或礦工）需要解決一個複雜的數學問題，稱為工作證明。這個問題通常是一個哈希函數的輸入，並要求找到特定的輸出，滿足特定的條件。這個問題的解決過程需要進行大量的計算，而且是具有隨機性的。解決問題的節點被稱為礦工，並且他們需要提供工作證明來證明他們完成了計算工作。

一旦一個節點找到了正確的工作證明，它就可以將該區塊添加到區塊鏈上。其他節點可以輕鬆地驗證這個工作證明的有效性，只需將該證明應用於相同的數學問題上即可驗證其正確性。通過這種方式，工作證明確保了節點必須投入一定的計算資源才能添加新的區塊，從而降低了對惡意行為者的攻擊可能性。

Proof of Work機制的一個重要特點是競爭性。因為節點們需要解決同一個問題，所以他們之間會進行競爭，以便第一個找到正確的工作證明並添加區塊到區塊鏈上。這也就意味著礦工必須擁有更多的計算資源（如計算能力和能源）才能有更高的概率成為下一個添加區塊的節點。

儘管Proof of Work是一個有效且廣泛使用的共識機制，但它也存在一些問題。首先，它需要大量的計算能力和能源消耗，這導致了高昂的運營成本。

其次，Proof of Work機制也可能引發礦工的中心化問題，因為那些擁有更多計算資源的節點有更高的概率獲得獎勵，這使得礦池（多個礦工共同合作挖礦）形成，有可能導致某些節點集中控制了整個區塊鏈網絡。

為了解決這些問題，一些新的共識機制如Proof of Stake（PoS）已經被提出並得到應用。PoS機制通過節點持有的加密貨幣數量來決定他們添加新區塊的權益，從而減少了計算能力和能源的消耗，並有助於達到更高的去中心化程度。

權益證明（Proof-Of-Stake）, PoS

Proof of Stake（PoS）是一種區塊鏈共識機制，與Proof of Work（PoW）相對應。在PoS機制中，節點被選為下一個區塊的添加者，並且他們的選擇是基於他們所持有的加密貨幣的數量，而不是計算能力。

在PoS機制中，持有加密貨幣的節點被稱為權益者（stakers）。每個權益者都有機會被選為下一個區塊的添加者，並獲得相應的獎勵。權益者的機會被選中的概率與他們持有的加密貨幣數量成正比，也就是說，持有更多貨幣的節點有更高的概率獲得獎勵。

與PoW不同，PoS機制不需要節點進行大量的計算工作。取而代之的是，節點需要在網絡上鎖定一定數量的加密貨幣作為抵押品。這種抵押品的數量反映了權益者在區塊鏈網絡中的參與程度和利益，並且可以作為選擇下一個區塊添加者的依據。

PoS機制的優勢之一是節能和環保。由於不需要進行大量的計算工作，PoS消耗的能源較少，這對於環境友好型區塊鏈項目尤其重要。此外，PoS機制減少了中心化的風險，因為節點被選中的概率與他們持有的貨幣數量成正比，而不是與計算能力相關。

然而，PoS機制也存在一些挑戰和風險。一個主要的挑戰是所謂的"Nothing at Stake"問題，即節點可以同時參與多個分支，並在分支間進行雙重花費攻擊。這是因為在PoS機制中，選擇分支的成本相對較低，而且沒有額外的計算資源需求。為了解決這個問題，一些PoS區塊鏈項目採取了額外的機制，如罰款或貨幣鎖定期，來防止節點進行惡意行為。

總的來說，PoS機制提供了一種替代PoW的共識機制，並且具有節能、環保和降低中心化風險的潛力。然而，每種共識機制都有其優點和局限性，適用的具體情況取決於項目的目標、需求和環境條件。

更詳細可以參考【區塊鏈 Blockchain – 共識機制之權益證明 Proof-Of-Stake - Samson’s Blog】

Nothing-at-Stake攻擊（無損攻擊）

Nothing-at-Stake攻擊（無損攻擊）是一種可能出現在Proof of Stake（PoS）共識機制中的攻擊方式。該攻擊利用了PoS機制的特性，使得節點可以在分叉的區塊鏈上同時參與多個分支，而不需要承擔任何成本或風險。

在PoS機制中，權益者（stakers）需要在網絡上鎖定一定數量的加密貨幣作為抵押品，以獲得權益。當選擇下一個區塊的添加者時，通常是根據權益者所持有的加密貨幣數量來進行選擇。這意味著持有更多貨幣的節點有更高的概率獲得獎勵並添加新的區塊。

在Nothing-at-Stake攻擊中，一個權益者可以同時在分叉的區塊鏈上創建多個分支，並在每個分支上添加區塊，而不需要承擔任何成本。這是因為在PoS機制中，選擇分支的成本相對較低，並且節點不需要進行大量的計算工作。因此，一個權益者可以在多個分支上同時參與，並將自己的資源分散到不同的分支中。

這種攻擊的結果是導致分叉的區塊鏈上存在多個有效的分支，並且權益者可以在每個分支上添加區塊。這會導致區塊鏈的確定性和一致性問題，因為不同的節點可能看到不同的區塊鏈狀態。

Nothing-at-Stake攻擊的解決辦法是引入額外的機制來防止權益者進行這種攻擊。這些機制可能包括罰款機制或貨幣鎖定期。罰款機制可以使得權益者在同時參與多個分支時面臨損失，從而降低了進行攻擊的動機。貨幣鎖定期則要求在權益者切換到新的分支之前需要等待一段時間，這樣可以使得分支間的選擇更加明確，並增加攻擊的成本和風險。

總結來說，Nothing-at-Stake攻擊是一種利用PoS機制特性的攻擊方式，使得權益者可以在分叉的區塊鏈上同時參與多個分支而不承擔成本。這種攻擊可能導致確定性和一致性問題。為了解決這個問題，需要引入額外的機制來增加攻擊的成本和風險。

拜占庭容錯（Byzantine Fault Tolerance, BFT）演算法

拜占庭容錯（Byzantine Fault Tolerance, BFT）是一種在分散式計算領域中的演算法，旨在保護系統免於所謂的拜占庭故障（即使是在有故障或惡意節點的情況下也能達成共識）。一個具有拜占庭容錯的系統可以繼續運行，即使一部分節點無法回應，回應錯誤，或者回應惡意信息。

BFT演算法通常需要一個協議，來確保所有節點在故障或惡意的干擾下也能達成共識。最為人所知的BFT演算法是羅馬軍團演算法（the Byzantine Generals’ Algorithm）。該演算法需要所有節點都能互相通訊，並且只有當超過三分之二的節點是誠實的（即，不是拜占庭節點），系統才能達成共識。

舉例來說，假設有一個由 4 個節點的系統，其中 1 個是拜占庭節點。在這種情況下，即使拜占庭節點嘗試分散系統的一致性，其他 3 個誠實的節點仍然可以透過他們的協議達成共識。即使有一個節點返回錯誤或惡意的信息，只要有超過一半的節點能達成共識，系統就能繼續運行。

然而，該演算法在面對大規模系統時可能效率不高，因為每個節點都必須與其他所有節點通訊。為了解決這一問題，研究人員開發了多種改進的BFT演算法，例如實用拜占庭容錯（Practical Byzantine Fault Tolerance，PBFT）等等，這些都是為了提高在面對拜占庭故障時的效率和效能。

實現拜占庭容錯的演算法有許多，其中最著名的可能是實用拜占庭容錯（Practical Byzantine Fault Tolerance, PBFT）演算法。PBFT透過一種稱為"三階段握手"的過程，確保了系統中的所有節點都能達成共識。此外，還有很多其他的演算法，例如 Federated Byzantine Agreement（聯盟拜占庭協議）等等。

拜占庭容錯是分散式系統設計的一個重要環節，尤其是在區塊鏈和分散式資料庫等領域。通過實現拜占庭容錯，系統設計者可以確保他們的系統在面對各種故障和攻擊時，都能保持穩定和正確的運作。

實用拜占庭容錯（Practical Byzantine Fault Tolerance，PBFT）

實用拜占庭容錯（Practical Byzantine Fault Tolerance，PBFT）是一種共識算法，旨在解決分散式系統中可能存在的拜占庭錯誤問題。拜占庭錯誤是指在分散式系統中的節點之間存在著任意形式的錯誤行為，例如節點故障、節點篡改或惡意行為等。

PBFT的目標是在存在最多f個拜占庭錯誤的情況下，達成一致並保護系統的正確性和安全性。它基於共識算法，要求系統中的所有節點通過相互之間的通訊達成一致的結論，即使在存在拜占庭錯誤的情況下也能保證正確性。

PBFT的運作原理如下：

角色：系統中的節點分為主節點（primary）和副本節點（replica）。主節點負責提議和領導共識過程，而副本節點則驗證和接受主節點的提議。
預准備階段（Pre-prepare phase）：主節點向所有副本節點發送預准備消息，包含提議的內容。副本節點驗證預准備消息的合法性，確認提議內容的有效性。
准備階段（Prepare phase）：當副本節點驗證預准備消息後，將回覆一個確認消息（prepare message）給其他節點，表示該提議是有效的。這些確認消息由主節點收集並廣播給所有節點。
提議階段（Commit phase）：當主節點收到足夠的確認消息，確保有足夠多的節點同意該提議，它就會向副本節點發送確認消息（commit message），要求副本節點執行該提議。
執行階段（Execute phase）：副本節點收到足夠的確認消息後，執行該提議的操作，並將執行結果傳播給其他節點。
完成階段（Reply phase）：主節點收到足夠的執行結果後，將結果回覆給客戶端。

PBFT通過共識階段的多次循環來確保系統的安全性和正確性。它需要2f + 1個節點來容忍最多f個拜占庭錯誤，並保證系統的正常運行。

PBFT具有良好的容錯性和安全性，但也存在一些限制。例如，它需要大量的網絡通訊，尤其在節點數量很多時，通訊開銷會變得很高。此外，當存在惡意行為的節點時，PBFT的性能可能會受到影響。

總的來說，PBFT是一種實用的共識算法，適用於需要高度安全性和容錯性的分散式系統，例如區塊鏈和分布式資料庫。它通過多階段的共識過程確保系統的一致性和正確性，同時能夠容忍一定數量的拜占庭錯誤。

想知道更詳細，推薦可以看【若想搞懂區塊鏈就不能忽視的經典：PBFT】

這個主題的延伸可探討的問題包括：

如何提高拜占庭容錯演算法的效率？
工作量證明與權益證明在實際應用中的優劣比較？
現有的拜占庭容錯演算法是否足夠應對實際運作中的分散式系統？
為什麼某些分散式系統選擇使用拜占庭容錯，而其他則不？
如何確保在面對更複雜的拜占庭攻擊時，分散式系統的安全性？
如何減少達成共識所需的能源消耗，特別是在使用工作量證明這種需要大量計算的方法時？

參考資料 👐

最後，如果你覺得我的分享對你有幫助，請給予我一個愛心，並且分享這篇文章，這將是對我最大的鼓勵！

Algo on Jenny blog

約瑟夫問題（Josephus Problem）

介紹

問題的背景是這樣的：

問題的目標

約瑟夫問題並不僅限於具體的數字，而是一個普遍的抽象問題，可以用數學方式來解決。

基於遞迴的解法如下：

需要注意的是，

李永樂老師的講解

紀錄

流程圖

實作

拜占庭問題 Byzantine Problem

拜占庭問題 Byzantine Problem

解決拜占庭問題的一種方法是使用拜占庭容錯（Byzantine Fault Tolerance, BFT）演算法。

工作證明（Proof of Work，PoW）

權益證明（Proof-Of-Stake）, PoS

Nothing-at-Stake攻擊（無損攻擊）

拜占庭容錯（Byzantine Fault Tolerance, BFT）演算法

實用拜占庭容錯（Practical Byzantine Fault Tolerance，PBFT）

這個主題的延伸可探討的問題包括：

參考資料 👐