Я хотел бы финансировать некоторые вещи. А некоторые нет. Неделю назад сочинил своеобразный алгоритм, вбросил его в твиттер на критику.

Основные идеи алгоритма

  • Хочешь что-то сделать, но дорого делать это одному.
  • Инициируешь голосование в группе.
  • Люди могут отказаться и их это вообще не будет касаться.
  • Будут ли они пользоваться совместно приобретённым благом или нет — за рамками этого алгоритма.
  • Расходы делятся тем или иным способом среди согласившихся.

Вообще это близко к PAXOS и здесь нужно достичь консенсуса — тратим ли группой деньги или нет. Я использую в этой схеме координатора, им может быть инициатор голосования или выделенный человек, значения не имеет, мы не заморачиваемся за отказоустойчивость, так как алгоритм предназначен для исполнения людьми.

Пример

  1. Координатор: VOTE-REQUEST, давайте купим видеонаблюдение в подъезд, стоит 50000 рублей.
    • Собственник1: VOTE, готов скинуть 5000 рублей.
    • Собственник2. REJECT
    • СобственникN. VOTE, готов скинуть 2500 рублей.
    • Координатор: суммирует числа, присланные в VOTE-сообщениях.
    • Координатор: принимает предварительное решение и сумму, требуемую от каждого участника.
    • Координатор: ADOPT, скидываемся по 2000 рублей
    • Собственник1: ОК
    • СобственникN: ОК
    • Координатор: ACCEPT, COMMIT

Касательно пункта 7 — здесь может быть два варианта развития событий. Все собственники скидываются поровну или по минимально возможной сумме.

Случай “поровну” не особо осмысленный и справедливый как может показаться — он отсекает людей, готовых скинуться, но не дотягивающих до усреднённого необходимого значения. То есть человек который хотел бы скинуть 1000 рублей будет отброшен, а остальным придётся скидываться на 1000/N больше (каждому). Если кажется что предлагать меньше — нечестная стратегия, то нужно вспомнить, что есть стратегия не платить вообще — REJECT. Но в обоих случаях есть риск не добиться общей цели, так как не хватит “предварительно собранных” денег.

В случае с “минимально возможной суммой” от разных людей могут потребоваться разные суммы. В таком случае в пункте 8 сообщение ADOPT будет не broadcast, а unicast.