Chord
160bitsのノードIDが各ノードに割り当てられる つまりノードの責任範囲はPredecessorから自分のIDまでである
各ノードはSuccessorとPredecessor以外に2の冪乗離れたノードの情報をもつ。これをFinger Tableという Finger Tableを経路表として利用することで通信コストは対数オーダー（O(log n)）になる。速い 耐故障性のために、複数先のノードまでを保持するSuccessor Listを持つ
Chordには検索、参加、安定化の3種類の手続きが存在する
検索手続き
最初に検索を受けたノードが自分のFinger Tableから最も検索キーに近いノード(cpf : Closest Preceding Finger)を探す
そのノードのSuccessorを問合せ、それがキーと一致しなかったらさらにそのノードのcpfを探す
検索キーに一致するノードが見つかるまでこれを繰り返す
参加手続き
まず新しく参加したノードは自分のIDをキーに検索をかける。その結果が自分のSuccessorであり、SuccessorのPredecessorが自分のPredecessorになる
上の手続きが完了したら自分のSuccessorとPredecessorに自分が各役割になったことを通知する
SuccessorのもつFinger Tableをコピーして、後に説明する安定化手続きで修正する
この時、Successorと距離が近いほどコピー時点で比較的正確なFinger Tableになる
安定化手続き
SuccessorとPredecessorを間違ったもので登録していると、間違った検索結果を返してしまうことがあるため最も頻繁に更新しなければならない。またFinger Tableが間違っていると、検索効率を下げてしまうのでこちらもまあまあ頻繁に更新しなければならない
SuccessorにPredecessorを問合せる。本来検索結果は自分になるはず
結果が返ってこない場合は障害とみなしてSuccessor Listから新しいSuccessorを登録する
違う結果が返ってきた場合は結果のノードをSuccessorに登録する
Finger Tableの中のランダムなノードのIDを検索して、違うノードが返ってきたらそれをFingerとして登録する
安定化手続きは以上の2つを定期的に繰り返す。頻繁にやりすぎるとFlooding Searchと同じく処理能力と帯域を食い散らかしてしまうのでバランスを取る必要がある。この論文でどれくらい頻繁に安定化手続きを行うべきかが述べられている