hailin
/
rwadurian
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
rwadurian/backend/mpc-system/PARTY_ROLE_VERIFICATION_REP...

12 KiB
Raw Permalink Blame History

Party Role Labels Implementation - Verification Report

Date: 2025-12-05 Commit: e975e9d - "feat(mpc-system): implement party role labels with strict persistent-only default" Environment: Docker Compose (Local Development)

1. Implementation Summary

1.1 Overview

Implemented Party Role Labels (Solution 1) to differentiate between three types of server parties:

  • Persistent: Stores key shares in database permanently
  • Delegate: Generates user shares and returns them to caller (doesn't store)
  • Temporary: For ad-hoc operations

1.2 Core Changes

Files Modified

  1. services/session-coordinator/application/ports/output/party_pool_port.go

    • Added PartyRole enum (persistent, delegate, temporary)
    • Added PartyEndpoint.Role field
    • Added PartySelectionFilter struct with role filtering
    • Added SelectPartiesWithFilter() and GetAvailablePartiesByRole() methods

  2. services/session-coordinator/infrastructure/k8s/party_discovery.go

    • Implemented role extraction from K8s pod labels (party-role)
    • Implemented GetAvailablePartiesByRole() for role-based filtering
    • Implemented SelectPartiesWithFilter() with role and count requirements
    • Default role: persistent if label not found

  3. services/session-coordinator/application/ports/input/session_management_port.go

    • Added PartyComposition struct with role-based party counts
    • Added optional PartyComposition field to CreateSessionInput

  4. services/session-coordinator/application/use_cases/create_session.go

    • Implemented strict persistent-only default policy (lines 102-114)
    • Implemented selectPartiesByComposition() method with empty composition validation (lines 224-284)
    • Added clear error messages for insufficient parties

  5. k8s/server-party-deployment.yaml

    • Added label: party-role: persistent (line 25)

  6. k8s/server-party-api-deployment.yaml (NEW FILE)

    • New deployment for delegate parties
    • Added label: party-role: delegate (line 25)
    • Replicas: 2 (for generating user shares)

2. Security Policy Implementation

2.1 Strict Persistent-Only Default

When PartyComposition is nil (not specified):

  • System MUST select only persistent parties
  • If insufficient persistent parties available → Fail immediately with clear error
  • NO automatic fallback to delegate/temporary parties
  • Error message: "insufficient persistent parties: need N persistent parties but not enough available. Use PartyComposition to specify custom party requirements"

Code Reference: create_session.go:102-114

2.2 Empty PartyComposition Validation

When PartyComposition is specified but all counts are 0:

  • System returns error: "PartyComposition specified but no parties selected: all counts are zero and no custom filters provided"
  • Prevents accidental bypass of persistent-only requirement

Code Reference: create_session.go:279-281

2.3 Threshold Security Guarantee

  • Default policy ensures MPC threshold security by using only persistent parties
  • Persistent parties store shares in database, ensuring T-of-N shares are always available for future sign operations
  • Delegate parties (which don't store shares) are only used when explicitly specified via PartyComposition

3. Docker Compose Deployment Verification

3.1 Build Status

Command: ./deploy.sh build Status: ✅ SUCCESS Images Built:

  1. mpc-system-postgres (postgres:15-alpine)
  2. mpc-system-rabbitmq (rabbitmq:3-management-alpine)
  3. mpc-system-redis (redis:7-alpine)
  4. mpc-system-session-coordinator
  5. mpc-system-message-router
  6. mpc-system-server-party-1/2/3
  7. mpc-system-server-party-api
  8. mpc-system-account-service

3.2 Deployment Status

Command: ./deploy.sh up Status: ✅ SUCCESS Services Running (10 containers):

Service Status Ports Notes
mpc-postgres Healthy 5432 (internal) PostgreSQL 15
mpc-rabbitmq Healthy 5672, 15672 (internal) Message broker
mpc-redis Healthy 6379 (internal) Cache store
mpc-session-coordinator Healthy 8081:8080 Core orchestration
mpc-message-router Healthy 8082:8080 Message routing
mpc-server-party-1 Healthy 50051, 8080 (internal) Persistent party
mpc-server-party-2 Healthy 50051, 8080 (internal) Persistent party
mpc-server-party-3 Healthy 50051, 8080 (internal) Persistent party
mpc-server-party-api Healthy 8083:8080 Delegate party
mpc-account-service Healthy 4000:8080 Application service

3.3 Health Check Results

# Session Coordinator
$ curl http://localhost:8081/health
{"service":"session-coordinator","status":"healthy"}

# Account Service
$ curl http://localhost:4000/health
{"service":"account","status":"healthy"}

Status: ✅ All services responding to health checks

4. Known Limitations in Docker Compose Environment

4.1 K8s Party Discovery Not Available

Log Message:

{"level":"warn","message":"K8s party discovery not available, will use dynamic join mode",
 "error":"failed to create k8s config: stat /home/mpc/.kube/config: no such file or directory"}

Impact:

  • Party role labels (party-role) from K8s deployments are not accessible in Docker Compose
  • System falls back to dynamic join mode (universal join tokens)
  • PartyPoolPort is not available, so selectPartiesByComposition() logic is not exercised

Why This Happens:

  • Docker Compose doesn't provide K8s API access
  • Party discovery requires K8s Service Discovery and pod label queries
  • This is expected behavior for non-K8s environments

4.2 Party Role Labels Not Testable in Docker Compose

The following features cannot be tested in Docker Compose:

  1. Role-based party filtering (SelectPartiesWithFilter)
  2. PartyComposition-based party selection
  3. Strict persistent-only default policy
  4. K8s pod label reading (party-role)

These features require actual Kubernetes deployment to test.

5. What Was Verified

5.1 Code Compilation ✅

  • All modified Go files compile successfully
  • No syntax errors or type errors
  • Build completes on both Windows (local) and WSL (Docker)

5.2 Service Deployment ✅

  • All 10 services start successfully
  • All health checks pass
  • Services can connect to each other (gRPC connectivity verified in logs)
  • Database connections established
  • Message broker connections established

5.3 Code Logic Review ✅

  • Strict persistent-only default policy correctly implemented
  • Empty PartyComposition validation prevents loophole
  • Clear error messages for insufficient parties
  • Role extraction from K8s pod labels correctly implemented
  • Role-based filtering logic correct

6. What Cannot Be Verified Without K8s

6.1 Runtime Behavior

  1. Party Discovery: K8s pod label queries
  2. Role Filtering: Actual filtering by party-role label values
  3. Persistent-Only Policy: Enforcement when persistent parties insufficient
  4. Error Messages: Actual error messages when party selection fails
  5. PartyComposition: Custom party mix selection

6.2 Integration Testing

  1. Creating a session with default (nil) PartyComposition → should select only persistent parties
  2. Creating a session with insufficient persistent parties → should return clear error
  3. Creating a session with empty PartyComposition → should return validation error
  4. Creating a session with custom PartyComposition → should select correct party mix

7. Next Steps for Full Verification

7.1 Deploy to Kubernetes Cluster

To fully test Party Role Labels, deploy to actual K8s cluster:

# Apply K8s manifests
kubectl apply -f k8s/namespace.yaml
kubectl apply -f k8s/configmap.yaml
kubectl apply -f k8s/secrets.yaml
kubectl apply -f k8s/postgres-deployment.yaml
kubectl apply -f k8s/rabbitmq-deployment.yaml
kubectl apply -f k8s/redis-deployment.yaml
kubectl apply -f k8s/server-party-deployment.yaml
kubectl apply -f k8s/server-party-api-deployment.yaml
kubectl apply -f k8s/session-coordinator-deployment.yaml
kubectl apply -f k8s/message-router-deployment.yaml
kubectl apply -f k8s/account-service-deployment.yaml

# Verify party discovery works
kubectl logs -n mpc-system -l app=mpc-session-coordinator | grep -i "party\|role\|discovery"

# Verify pod labels are set
kubectl get pods -n mpc-system -l app=mpc-server-party -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.party-role}{"\n"}{end}'
kubectl get pods -n mpc-system -l app=mpc-server-party-api -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.party-role}{"\n"}{end}'

7.2 Integration Testing in K8s

  1. Test Default Persistent-Only Selection:

    curl -X POST http://<account-service>/api/v1/accounts \
  -H "Content-Type: application/json" \
  -d '{"user_id": "test-user-1"}'

# Expected: Session created with 3 persistent parties
# Check logs: kubectl logs -n mpc-system -l app=mpc-session-coordinator | grep "selected persistent parties by default"

  2. Test Insufficient Persistent Parties Error:

    # Scale down persistent parties to 2
kubectl scale deployment mpc-server-party -n mpc-system --replicas=2

# Try creating session requiring 3 parties
curl -X POST http://<account-service>/api/v1/accounts \
  -H "Content-Type: application/json" \
  -d '{"user_id": "test-user-2"}'

# Expected: HTTP 500 error with message "insufficient persistent parties: need 3 persistent parties but not enough available"

  3. Test Empty PartyComposition Validation:

    • Requires API endpoint that accepts PartyComposition parameter
    • Send request with PartyComposition: {PersistentCount: 0, DelegateCount: 0, TemporaryCount: 0}
    • Expected: HTTP 400 error with message "PartyComposition specified but no parties selected"

  4. Test Custom PartyComposition:

    • Send request with PartyComposition: {PersistentCount: 2, DelegateCount: 1}
    • Expected: Session created with 2 persistent + 1 delegate party
    • Verify party roles in session data

8. Conclusion

8.1 Implementation Status: ✅ COMPLETE

  • All code changes implemented correctly
  • Strict persistent-only default policy enforced
  • Empty PartyComposition validation prevents loophole
  • Clear error messages for insufficient parties
  • Backward compatibility maintained (optional PartyComposition)

8.2 Deployment Status: ✅ SUCCESS (Docker Compose)

  • All services build successfully
  • All services deploy successfully
  • All services healthy and responding
  • Inter-service connectivity verified

8.3 Verification Status: ⚠️ PARTIAL

  • ✅ Code compilation and logic review
  • ✅ Docker Compose deployment
  • ✅ Service health checks
  • ❌ Party role filtering runtime behavior (requires K8s)
  • ❌ Persistent-only policy enforcement (requires K8s)
  • ❌ Integration testing (requires K8s)

8.4 Readiness for Production

Code Readiness: ✅ READY Testing Readiness: ⚠️ REQUIRES K8S DEPLOYMENT FOR FULL TESTING Deployment Readiness: ✅ READY (K8s manifests prepared)

9. User Confirmation Required

The Party Role Labels implementation is complete and successfully deployed in Docker Compose. However, full runtime verification requires deploying to an actual Kubernetes cluster.

Options:

  1. Proceed with K8s deployment for full verification
  2. Accept partial verification (code review + Docker Compose deployment)
  3. Create integration tests that mock K8s party discovery

Awaiting user instruction on next steps.